<div dir="ltr">I just wanted to say that removing CSE'ing pointers based on an icmp would simplify the -fstrict-vtable-pointers model.<div>We try to CSE loads and stores from the same pointer (modulo zero GEPs and bitcasts) that have the !invariant.group metadata. But we may have two different pointers with different provenances that compare equal (e.g. the pointer before and after a C++ placement new). In those cases we don't want to CSE the two different pointers, so we add the <a href="https://llvm.org/docs/LangRef.html#llvm-strip-invariant-group-intrinsic" target="_blank">llvm.strip.invariant.group</a> intrinsic before an icmp to prevent GVN from CSE'ing the pointers given a true icmp. If we prevented CSE'ing based on icmp, we wouldn't need these strip intrinsics.</div><div><br></div><div>Perhaps to recover some lost optimizations (e.g. I've seen (a == b ? a : b => b) missed due to adding intrinsics due to -fstrict-vtable-pointers) we could do a late pass (right before the codegen pipeline?) where we allow CSE'ing pointers based on icmp and ptrtoint/inttoptr simplification but disallow any pointer provenance optimizations, and make sure no later optimizations take advantage of those. The codegen pipeline probably doesn't have any optimizations based on pointer provenance?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 27, 2021 at 9:15 PM comex via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</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">On Wed, Jun 23, 2021 at 8:52 AM Ralf Jung via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> However, I am a bit worried about what happens when we eventually add proper<br>
> support for 'restrict'/'noalias': the only models I know for that one actually<br>
> make 'ptrtoint' have side-effects on the memory state (similar to setting the<br>
> 'exposed' flag in the C provenance TS). I can't (currently) demonstrate that<br>
> this is *required*, but I also don't know an alternative. So if this remains the<br>
> case, and if we say "load i64" performs a ptrtoint when needed, then that would<br>
> mean we could not do dead load elimination any more as that would remove the<br>
> ptrtoint side-effect.<br>
<br>
Though, of course, dead loads could be replaced with some hypothetical<br>
new instruction that has *only* the ptrtoint side-effect (and doesn't<br>
produce any assembly).  And such an instruction could be subject to<br>
further transformations.<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>