[LLVMdev] Strange pointer aliasing behaviour

[Dan Gohman]

On Jun 28, 2010, at 3:19 PM, Eugene Toder wrote:

> I think scev-aa does not succeed on the original example, because
> front ends do not put "nsw" on signed addition, so according to llvm
> rules addition can overflow and i can be < 0.

Actually, the front-end does put nsw there. The nsw gets lost during
optimization though. And even when nsw is re-introduced manually,
scev-aa loses track of it. These things are theoretically fixable
though.

scev-aa is still somewhat experimental; it's using ScalarEvolution in
a relatively unusual manner, and ScalarEvolution hasn't been
specifically tuned this way.

> Also, if original example used unsigned type (e.g. size_t, which is
> very common), I don't think ir can express the fact that i is
> guaranted to be >= 0.

Right; LLVM IR currently lacks a away to represent arbitrary value
constraints like that. An odd possibility though is to observe
that i is always less than some value on each iteration, and it's
only stepping by 1, so it can never wrap.

> Another line of reasoning is that if
> sizeof(i)*8+log2(sizeof(_data[0])) > address_size_in_bits, overflowing
> i requires going out of bounds when storing to _data[i] (because
> address space can't contain objects large enough). Can this be used
> for alias analysis?

Yes, something like this sounds theoretically possible.

Dan