[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/Bitcode/Writer/BitcodeWriter.cpp lib/VMCore/AsmWriter.cpp test/Assembler/flags-plain.ll test/Assembler/flags.ll

[Dan Gohman]

On Jul 29, 2009, at 9:44 AM, Török Edwin wrote:


> On 2009-07-29 19:26, Dan Gohman wrote:
>
>> On Jul 28, 2009, at 11:48 PM, Chris Lattner wrote:
>>
>>
>>
>>
>>
>>> On Jul 27, 2009, at 2:53 PM, Dan Gohman wrote:
>>>
>>>
>>>
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=77259&view=rev
>>>>
>>>> Log:
>>>>
>>>> Add a new keyword 'inbounds' for use with getelementptr. See the
>>>>
>>>> LangRef.html changes for details.
>>>>
>>>>
>>>>
>>> The langref changes look nice.  The choice of "inbounds" is a little
>>>
>>> strange to me, isn't this flag mostly about wrapping behavior when
>>>
>>> overflow happens?
>>>
>>>
>>>
>>
>>
>> It turns out that avoiding wrapping and staying in bounds are  
>> basically
>>
>> the same thing, since LLVM doesn't specify where in the address space
>>
>> it will allocate an object.
>>
>>
>>
>>
>>
>>> Will "inbounds" be the default generated by the llvm-gcc/clang  
>>> front-
>>>
>>> ends?  If so, it would be nice to invert the sense of the bit so it
>>>
>>> doesn't show up in all the .ll files making them really noisy.
>>>
>>>
>>>
>>
>>
>>
>>
>> I'm planning for it to be the default behavior.  I'm open to  
>> discussion;
>>
>> there are pros and cons either way.
>>
>
> Hi Dan,
>
> 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).
>
> Requiring a getelementptr to be inbounds is rather strong, since there
> are optimizations that can create GEPs that are not inbounds (as shown
> above).
> Either those optimizations should then clear the flag (any  
> optimization
> that moves GEPs out of a BB, or over a call), or inbounds should only
> mean that it is 'inbounds'
> when dereferenced.

The strong meaning of inbounds is what I intend here. It represents
properties guaranteed by the C standard, among other things.

Yes, LICM, if-conversion, and other passes will need to clear the
flags when they move instructions, unless they can prove that they
don't need to.

Moving instructions past calls is a case that I hadn't considered.
I assume you mean that a call could resize the allocation, or could
deallocate and reallocate at the same address.

I think the way to handle this is to observe that LLVM IR allocation
mechanisms don't permit resizing, and don't provide a way to
force a reallocation to happen at the same address. A library
allocator could do either of these, but LLVM doesn't know when or
where library allocators allocate their storage, so I don't see any
cases where this could cause an actual problem. I guess this is
an argument in favor of defining inbounds in terms of integer
overflow rather than in terms of allocated objects. I'll think
about it.

Dan