[llvm-commits] [llvm] r77259 - in /llvm/trunk: docs/LangRef.html include/llvm/Bitcode/LLVMBitCodes.h include/llvm/Operator.h lib/AsmParser/LLLexer.cpp lib/AsmParser/LLParser.cpp lib/AsmParser/LLToken.h lib/Bitcode/Reader/BitcodeReader.cpp lib/Bit

[Török Edwin]

On 2009-07-29 22:49, Eli Friedman wrote:
> 2009/7/29 Török Edwin <edwintorok at gmail.com>:
>   
>> Its better if I give an example (in C, its easier that way):
>>
>> void foo(unsigned x)
>> {
>>     unsigned i;
>>    char *a = malloc(10);
>>    for (i=0;i<10;i++)
>>       if (x < 10)
>>            bar(a[x]);
>> }
>>
>> LICM can move the a+x computation before the loop, and thus not guarded
>> by the if.
>> If you compute (a+x) before the loop, it may or may not be out of
>> bounds, BUT when it is dereferenced
>> inside the if, it is guaranteed that x<10, thus it is inbounds.
>>     
>
> Exactly... and we consider the LICM transformation safe because the
> GEP is not used in any context where the undefined result translates
> into undefined behavior.  Again, it's the same way we treat an
> undefined shift; the computation doesn't lead to undefined behavior.
> Essentially, in the undefined cases, the result is equivalent to
> "undef".
>   

Ok, then I misunderstood what the intentions are wrt undefined results.

I've seen GVN turn code like this into undef:
%x = alloca i32
%1 = load %x
%2 = add %1, 6


-> %2 = add undef, 6

So I thought that you want to turn the result of the GEP into undef, and
"optimize away" subsequent GEPs, or uses of that GEP to undef.

Best regards,
--Edwin