[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

[Eli Friedman]

2009/7/29 Török Edwin <edwintorok at gmail.com>:
> 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

Right.. that's guaranteed to be undefined.

> 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.

Only if we can prove that it's always undef, which wouldn't be
possible for your given testcase.

-Eli