Mostly the same as and. We also have a check for a useless
llvm.ptrmask if the ptr is already known aligned.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/test/Transforms/InstSimplify/ptrmask.ll | ||
---|---|---|
28 | I don't think this fold is correct, but alive2 accepts it. I've filed https://github.com/AliveToolkit/alive2/issues/929. |
llvm/test/Transforms/InstSimplify/ptrmask.ll | ||
---|---|---|
28 | Oh, in that case a lot of this series is out the window. No need to review the rest of the series as this was assumed in A LOT of places, will refactor. |
llvm/test/Transforms/InstSimplify/ptrmask.ll | ||
---|---|---|
28 | Is there a way to do this simplification w.o breaking provenance? Or do all the null returns need to be properly removed? |
llvm/test/Transforms/InstSimplify/ptrmask.ll | ||
---|---|---|
28 | Would the following be acceptable? |
llvm/test/Transforms/InstSimplify/ptrmask.ll | ||
---|---|---|
28 | Does this being illegal imply that we don't need this nullness check here: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Analysis/ValueTracking.cpp#L5789 |
llvm/test/Transforms/InstSimplify/ptrmask.ll | ||
---|---|---|
28 | Folding these to null could definitely result in miscompilations for CHERI targets such as Morello since pointers include bounds metadata. It is possible to have a pointer with e.g. full address space bounds. If I mask that with zero I'd want a dereference able pointer that still has those bounds rather than null which is non-dereferenceable. I could imagine this kind of pattern coming up followed by some more pointer arithmetic which would be equivalent to %p with address=X (there is no such intrinsic in upstream LLVM, but the CHERI fork adds one that retains provenance and just updated the pointed-to address). |
I don't think this fold is correct, but alive2 accepts it. I've filed https://github.com/AliveToolkit/alive2/issues/929.