[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
Török Edwin
edwintorok at gmail.com
Wed Jul 29 09:44:02 PDT 2009
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.
Best regards,
--Edwin
More information about the llvm-commits
mailing list