[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]

On Wed, Jul 29, 2009 at 11:33 AM, Eli Friedman<eli.friedman at gmail.com> wrote:
> 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.

Oh, wait, I think I see what you mean.  The inbounds property does not
guarantee it is safe to load from the pointer in question.

-Eli