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

[Arthur Eubanks via llvm-dev]

I just wanted to say that removing CSE'ing pointers based on an icmp would
simplify the -fstrict-vtable-pointers model.
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 llvm.strip.invariant.group
<https://llvm.org/docs/LangRef.html#llvm-strip-invariant-group-intrinsic>
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.

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?

On Sun, Jun 27, 2021 at 9:15 PM comex via llvm-dev <llvm-dev at lists.llvm.org>
wrote:

> On Wed, Jun 23, 2021 at 8:52 AM Ralf Jung via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > However, I am a bit worried about what happens when we eventually add
> proper
> > support for 'restrict'/'noalias': the only models I know for that one
> actually
> > make 'ptrtoint' have side-effects on the memory state (similar to
> setting the
> > 'exposed' flag in the C provenance TS). I can't (currently) demonstrate
> that
> > this is *required*, but I also don't know an alternative. So if this
> remains the
> > case, and if we say "load i64" performs a ptrtoint when needed, then
> that would
> > mean we could not do dead load elimination any more as that would remove
> the
> > ptrtoint side-effect.
>
> Though, of course, dead loads could be replaced with some hypothetical
> new instruction that has *only* the ptrtoint side-effect (and doesn't
> produce any assembly).  And such an instruction could be subject to
> further transformations.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210913/c4fe48ea/attachment.html>