[llvm-dev] [RFC] Introducing a byte type to LLVM

[Juneyoung Lee via llvm-dev]

Hello Andrew,

> We can't retroactively weaken inttoptr semantics relative to what
frontends rely on--it should continue to have the semantics of a pointer
cast in C, which need to be handled more conservatively in LLVM.

I think it depends. If necessary, ptr/int cast semantics needs to be
weakened, as done in signed overflow.
Signed overflow is undefined behavior in C, but it yields poison in LLVM
because the C semantics prohibits free code motion of add nsw.
I believe its poison definition is successful and can still support useful
optimizations.

Thanks,
Juneyoung

On Sat, Jun 19, 2021 at 2:21 PM Andrew Trick <atrick at apple.com> wrote:

>
> On Jun 15, 2021, at 4:56 PM, John McCall via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> If we find that we’re generating too many unnecessary casts
> through integer types and it’s really blocking the optimizer too
> much, then we should consider the best solutions to those problems
> as they arise. It may be the case that we need a better solution
> for type conversions introduced through manual memcpy-like code
> so that we maintain the original provenance instead of adding
> explicit int<->pointer conversions that launder provenance.
> I don’t know that byte types are the best solution to that, but
> we can consider them.
>
>
> We can't retroactively weaken inttoptr semantics relative to what
> frontends rely on--it should continue to have the semantics of a pointer
> cast in C, which need to be handled more conservatively in LLVM.
>
> We can easily express the weaker memcpy semantics as "!raw" metadata on
> the load and inttoptr instructions. (I apologize if that was already
> mentioned in this thread.)
>
> Introducing a new type to communicate pointer semantics seems
> inconsistent. LLVM types primarily communicate ABI requirements from the
> frontend to the target. The semantics of pointer loads, and integer
> conversions can be specified on those operations and generated when the
> compiler emits byte-wise copies as opposed to semantic casts. We can expose
> a clang attribute or builtin for manual pointer copying.
>
> -Andy
>


-- 

Juneyoung Lee
Software Foundation Lab, Seoul National University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210621/03159a04/attachment.html>