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

[Andrew Trick via llvm-dev]

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210618/da30636d/attachment.html>