[LLVMdev] Canonicalization of ptrtoint/inttoptr and getelementptr

Dan Gohman dan433584 at gmail.com
Tue Sep 9 08:22:03 PDT 2014


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>


More information about the llvm-dev mailing list