[llvm] [llvm] Fix behavior of llvm.objectsize in presence of negative / large offset (PR #115504)
Harald van Dijk via llvm-commits
llvm-commits at lists.llvm.org
Wed Nov 13 18:16:49 PST 2024
================
@@ -580,6 +585,11 @@ bool llvm::getObjectSize(const Value *Ptr, uint64_t &Size, const DataLayout &DL,
if (!Data.bothKnown())
return false;
+ // We could compute an over-approximation in that situation, may be if
+ // Opts.EvalMode == Max, but let's bee conservative and bail out.
+ if (Data.Offset.isNegative())
+ return false;
----------------
hvdijk wrote:
Thinking about the reason why we are able to see that the best result is 1, it is because we don't combine the phis in the way the code does. We simply go over all possibilities, we have an object that is either `%p.then` in which case the result should ideally be `1`, or that is `%p.else` in which case the result should ideally be `0`. The maximum of those is `1`. Since we do not mentally combine the ranges of `%p.then` and `%p.else` in the way that the code does, but only combine the final results, we avoid the problem that we lose information in the earlier combining.
The combining of ranges makes sense to prevent exponential time complexity. But there may be other ways of preventing that. Your earlier `ConstantOffset` PR was a limited form of passing in information into the visitor about what subsequent operations will be performed on the ranges. I think revisiting that might be a good idea. It did not in its initial version handle all cases, but when combining that with the other improvements, I think it can, and I think it would result in us returning `1` here while keeping the out-of-bounds pointer handling in other cases intact.
https://github.com/llvm/llvm-project/pull/115504
More information about the llvm-commits
mailing list