[cfe-dev] Demystifying the byte type

[Johannes Doerfert via cfe-dev]

Hi George,

I only made it through part 1 for now but I figured I might forget if I 
don't reply directly:

 > Under the untyped memory model, we need to accept that every 
load/store has an implicit |ptrtoint|/|inttoptr| attached to it.

This is stated but I don't see it. Rather, a store of a pointer makes 
the pointer potentially escape (also see below).
Escaped pointers could show up as integers (among other things). So 
escaping a pointer (by any means) does an implicit
ptrtoint/inttoptr but not necessarily the store or the load. The 
transformation shown below that statement doesn't
contradict this view and SROA is still legal. All that happened is that 
SROA has first determined and then made
it explicit that the pointer (here %in) did not escape during the round 
trip through %mem. If, for example, %mem would
have been passed to an unknown function SROA would not have done this 
transformation because %in could now have
escaped through %mem. If %mem was casted to int and then loaded SROA 
would have made the escaping use explicit through
an ptrtoint: https://godbolt.org/z/PG3fj7qe4
Long story short, if you store a pointer (or cast it to an integer, or 
compare it other than some special ways) it might
escape and as anything could happen to it it looses its provenance. If 
you can show it doesn't escape, no provenance is
lost.


 > An alternative is to say that all pointer stores escape, which again 
has severe performance consequences and again do not align with all LLVM 
optimizations.

What optimizations do not treat a pointer stored away as an escaping 
use? That sounds like a problem.
[FWIW, I'm only aware of the Attributor but it ensures that all uses of 
the store are instead visited which makes this sound again (no escape 
can happen through the store).]

~ Johannes


On 10/15/21 13:41, George Mitenkov via cfe-dev wrote:
> Hi all,
>
> In May 2021, together with Nuno Lopes and Juneyoung Lee, we proposed to add
> a byte type in LLVM to fix load type punning issues. Initial RFC touched
> some subtle aspects of LLVM IR and its semantics, and sparked a lot of
> questions, concerns, and discussions.
>
> We decided to write a post that would summarise the thread and the
> complicated topic:
>
> https://gist.github.com/georgemitenkov/3def898b8845c2cc161bd216cbbdb81f
>
> We hope that our post clarifies initial concerns raised on the mailing
> list. As always, any questions, suggestions and advice are welcome!
>
> Thanks,
> George
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev