[LLVMdev] Canonicalization of ptrtoint/inttoptr and getelementptr

[Dan Gohman]

On Mon, Sep 8, 2014 at 8:36 PM, Reid Kleckner <rnk at google.com> wrote:

> On Mon, Sep 8, 2014 at 4:22 PM, Dan Gohman <dan433584 at gmail.com> wrote:
>
>> It looks a little silly to say this in the case of the integer constant
>> 5, and there are some semantic gray areas around extra-VM allocation, but
>> the same thing happens if the add were adding a dynamic integer value, and
>> then it's difficult to find a way to separate that case from the constant 5
>> case.
>>
>
> Could we say that constant integers have no objects associated with them?
> If so, we need a way to bless constant integers that *do* refer to real
> objects, such as ASan's shadow memory base.
>

> Then you should be able to take something like add a phi of constant ints
> to an inttoptr and transform that to a GEP, without explicitly calling out
> constant integers.
>

It's not pretty to have situations where dynamic values permit more
optimization than constants. If there's an expression which can be folded
to a constant int, should the constant folder avoid doing so, because it
might pessimize subsequent alias analysis?

Also, if you follow it to its semantic conclusion, even this isn't enough,
because 5 may be associated with *any* fixed address, in the same way that
p - 1000000 (which is valid to compute with a gep as long as you don't use
inbounds) is still associated with p's set, even though it's pointing
somewhere quite different. Associated-with is necessary but not sufficient
for a valid dereference.


>
>
>> In any case, the general advice is that people should prefer to use
>> getelementptr to begin with. LLVM's own optimizers were converted to use
>> getelementptr instead of ptrtoint+add+inttoptr even when they have to do
>> raw byte arithmetic.
>>
>
> I'm guessing the IR comes from C++ code that subtracts pointers, so it'd
> be good if we could figure this out.
>

A more complete testcase would be helpful here. This situation doesn't
arise from simple pointer differences, so we should look at what other
things it's interacting with to get here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140909/53cc6cac/attachment.html>