[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 21:35, Eli Friedman wrote:
> 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.
>   

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.

If you assume that computing an out-of-bounds GEP when the inbounds
attribute is applied leads to undefined results,
then the a+x computation is an undefined results as per your definition,
but it has a very well defined result in the original program,
it is just that due to code motion, the GEP is computed in a context
where it is no longer inbounds.

Best regards,
--Edwin