ritter-x2a wrote: > Maybe we could consider adding "ISD::PTRADD"? Lowers to ISD::ADD by default, > but targets that want to do weird things with pointer arithmetic could do > them.
That would be helpful. We'd still need an inbounds flag for ISD::PTRADD, but it would certainly be easier to make use of. I'll look into that. > One other concern, which applies to basically any formulation of this: Since > SelectionDAG doesn't have a distinct pointer type, you can't tell whether the > pointer operand was produced by an inttoptr. So in some cases, you have an > operation marked "inbounds", but it's ambiguous which object it's actually > inbounds to. This isn't really a problem at the moment because we do IR-level > transforms that remove inttoptr anyway, but if we ever do resolve the > IR-level issues, we should have some idea for how we propagate the fix to > SelectionDAG. I can see that's a problem if you'd want to infer that an operation is inbounds, or if you'd want to prove the absence (or presence) of poison/UB. But how is that a problem for generating code? If there is an inbounds flag on a (hypothetical) ISD::PTRADD, we can assume that the operation is inbounds with respect to whatever the address operand is pointing to, no matter if it's the result of integer operations, right? https://github.com/llvm/llvm-project/pull/131862 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
