[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 21:11, Eli Friedman wrote:
>> 2009/7/29 Török Edwin <edwintorok at gmail.com>:
>>
>>> Some optimization (I think LICM) moves getelementptr out of the
>>> basicblock where a predicate guarantees the inbounds property, thus you
>>> may get
>>> a getelementptr that computes an out of bounds value, but when the value
>>> is dereferenced it will always be in bounds (due to that predicate).
>>>
>>
>> That's fine; an invalid getelementptr has an undefined result, but
>> it's not undefined behavior by itself.  It's sort of like an undefined
>> shift.
>>
>>
>
> What happens when you load from it?
> Previously the code had no undefined result/undefined behaviour, if LICM
> moves it out of the BB
> you'll load from an undefined address. Or am I missing something?

I'm not following; if there's a load from a GEP with an undefined
result, that's undefined behavior regardless of whether the GEP moves.

-Eli