llvm dev - Sep 2014 - [LLVMdev] Canonicalization of ptrtoint/inttoptr and getelementptr

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.

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140908/e2c6d3e5/attachment.html>

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>

On Tue, Sep 9, 2014 at 7:26 AM, Dan Gohman <dan433584 at gmail.com> wrote:
> 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?
>

Actually, I got this backwards; in fact, it has the opposite problem.
Having different rules for constant ints than for other expressions means
the constant folder can't produce constant ints unless it can prove that
they aren't ever used in a way that would violate the new rules.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140909/b332f5a8/attachment.html>