<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 11, 2017 at 6:58 PM, Flamedoge <span dir="ltr"><<a href="mailto:code.kchoi@gmail.com" target="_blank">code.kchoi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><span class="m_-3746059428674675506gmail-im" style="font-size:12.8px">>> For now, the only sane solution IMHO, is to say that no alias implies<br>>> pointer inequality, regardless of the standards. Because the above can<br>>> occur in any situation noalias exists but they are allowed to be pointer<br>>> equal (as mentioned, it's trivial to make this happen in TBAA).<br><br></span><span style="font-size:12.8px">>Just to be clear, you're suggesting that we no longer mark malloc's</span><br style="font-size:12.8px"><span style="font-size:12.8px">>return value as noalias?<br></span><br></span>CMIIW, I believe the suggestion was treat p0 as unequal to p1 even under runtime check if p0 has NoAlias relation with p1. This will at least make ie. GVN to treat as if p0 and p1 aren't equal even if bits are, preventing transformation of p1 to p0, thus preventing reordering. I'm not a huge fan of this solution, and is quite hacky to GVN and pretty much to all the transformation passes :(.<div>The root cause is quite clear; you cannot assume malloc'd ptrs to have No-Alias without flow-sensitive, "lifetime" analysis.</div><div><br></div></div></blockquote><div><br></div><div>Apparently i was really unclear:<br>Making GVN do this would lose a tremendous amount of optimization.</div><div>You'd be better off turning off noalias than doing this.</div><div><br></div><div>I would actually just accept that this sucks and move on for now :P</div><div>Or modify clang to using the scoped noalias and solve the perofrmance bugs we have with that representation.</div><div><br></div><div>Long term, we need well defined and real lifetime start/end information that is semantically relevant, not just optional metadata.</div><div><br></div><div>(Or we need standards to stop making the lifetimes and aliasing issues ridiculously complex :P)</div></div></div></div>