[LLVMdev] proposed new rule for getelementptr

[Dan Gohman]

On Jul 23, 2009, at 10:55 AM, Mark Shannon wrote:
>
>> In practical terms, this proposal isn't a big change. It's a  
>> conceptual
>>
>> framework for describing assumptions that the optimizer is already
>>
>> making in many cases. It will help us resolve some cases where the
>>
>> optimizer's assumptions are contradictory. And, it sets the stage  
>> for a
>>
> I'm curious what these assumptions are, but its not important.

My first email aimed to make them explicit. Here's another example:

    @g = global i32

    %a = alloca i32
    %b = malloc i32
    %c = inttoptr 777770 to i32*

    %aa = getelementptr i32* %a, i64 %i
    %bb = getelementptr i32* %b, i64 %j
    %cc = getelementptr i32* %c, i64 %k
    %gg = getelementptr i32* @g, i64 %l

    store i32 0, i32* %aa
    store i32 1, i32* %bb
    store i32 2, i32* %cc
    store i32 3, i32* %gg

Here, %i, %j, %k, and %l are totally arbitrary values that the optimizer
knows nothing about. The optimizer will assume that all four stores are
to different memory locations. In theory, some truly crazy code could
figure out what values to use for %i, %j, %k, and/or %l to cause the
getelementptrs to overindex recklessly through the address space and
break this assumption. This the kind of thing that the optimizer
assumes doesn't happen.

>>
>>
>> I don't see anything problematic in your description here. Alias
>>
>> analysis
>>
>> may not be especially profitable in these circumstances, but I  
>> wouldn't
>>
>> guess that it would be unsafe.
>>
> Any tests I can do to find out if its safe?

I don't know of any. You can run GVN and LICM and so on to see if
they break anything, but of course that wouldn't prove that there
aren't any problems.

> One last question.
> If I were to turn off all optimisations, would that ensure that the
> final machine code semantics with the new GEP would be unchanged from
> the present GEP?
> In other words, will any of this affect to the code-generator?

It probably will at some point, to use alias-analysis info for
scheduling and other things. After all, CodeGen is just a highly
specialized optimizer ;-).

Dan