<div dir="ltr"><div dir="ltr">Hi Tim,</div><div><br></div>Thank you for the clarifying this.<div> <br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 9 Jul 2019 at 00:58, Tim Northover <<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Venkataramanan,<br>
<br>
On Mon, 8 Jul 2019 at 19:31, Venkataramanan Kumar via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> is it because the "obj.a" can alias with "ptr" ?<br>
<br>
Yes. At the IR level there's nothing to stop @bar from<br>
getelementptring backwards and accessing other parts of %1.<br>
<br>
I believe it would be somewhere between invalid and<br>
implementation-defined[*] at the C or C++ levels, but modelling that<br>
would be quite tricky. I thnk you'd need some kind of finer-grained<br>
escape analysis, supported by metadata (because there are constructs<br>
with otherwise very similar IR that *are* valid, for example if obj<br>
was an int[2]).<br>
<br>
Cheers.<br>
<br>
Tim.<br>
<br></blockquote><div><br></div><div>So we can still do some inter procedural analysis, and check if only the passed bytes is accessed in all those escaping places?</div><div> <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[*] Casts to/from ints are implementation-defined, so a compiler could<br>
allow it via "(int *)((uintptr_t)x - 4)" regardless of what the<br>
standard otherwise says. I don't recall seeing any discussion on<br>
whether Clang does or wants to do that.<br></blockquote><div><br></div><div>regards,</div><div>Venkat. </div></div></div></div>