[PATCH] D110245: [ConstantFolding] Fold ptrtoint(gep i8 null, x) -> x

[Alexander Richardson via Phabricator via llvm-commits]

arichardson created this revision.
arichardson added reviewers: nikic, lebedev.ri, reames.
Herald added subscribers: jrtc27, hiraditya.
arichardson requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

I was looking at some missed optimizations in CHERI-enabled targets and
noticed that we weren't removing vtable indirection for calls via known
pointers-to-members. The underlying reason for this is that we represent
pointers-to-function-members as {i8 addrspace(200)*, i64} and generate the
constant offsets using (gep i8 null, <index>). We use a constant GEP here
since inttoptr should be avoided for CHERI capabilities. The pointer-to-member
call uses ptrtoint to extract the index, due to this missing fold we can't
infer the actual value loaded from the vtable.
This is the initial constant folding change for this pattern, I will add
InstSimplify/InstCombine folds as a follow-up.

We could fold all ptrtoint(inbounds GEP) to zero here since that is the
only valid offset for an inbounds GEP. If the offset is not zero, that GEP
is poison so returning 0 is valid (https://alive2.llvm.org/ce/z/Gzb5iH).
However, Clang currently generates inbounds GEPs on NULL for hand-written
offsetof expressions, so this risks miscompilation.

FIXME: is this transformation valid for non-integral pointers?


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D110245

Files:
  llvm/lib/Analysis/ConstantFolding.cpp
  llvm/test/Transforms/InstCombine/ptrtoint-nullgep.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D110245.374215.patch
Type: text/x-patch
Size: 23998 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210922/9239c264/attachment.bin>