[LLVMdev] -instcombine introduces "undef" values to the IR.

[Nick Lewycky]

On 11 June 2014 14:01, Paul Vario <paul.paul.mit at gmail.com> wrote:

> Thanks a lot for the clarification! So if my input .ll is not expected to
> contain any of the above mentioned weird corner cases, but, after
> -instcombine, ends up containing "undef" values, then it must be that the
> input .ll has bugs unknown to me, right?
>

Well, yeah, but how do you know whether you got one of those corner cases?

There is a tool to detect likely bugs in .ll files, "opt -lint". Maybe that
will help?


> On Wed, Jun 11, 2014 at 3:09 PM, Nick Lewycky <nlewycky at google.com> wrote:
>
>> On 11 June 2014 12:26, Paul Vario <paul.paul.mit at gmail.com> wrote:
>>
>>> Hi Fellows,
>>>
>>>      If a .ll file contains no "undef"'s, does it necessarily mean that
>>> every value is properly initialized before use in the IR? What confuses me
>>> is that I notice that -instcombine can introduce "undef" to the previously
>>> undef-clean .ll file ... is it always safe to use -instcombine  as one of
>>> the preprocessing pass? Thanks.
>>>
>>
>> Yes, there's all manner of weird corner cases where it will. PHI nodes
>> that are cyclic and therefore dead, a provably invalid call to a library
>> function (sqrt negative), shift operations that provably shift out of
>> bounds, ... often it inserts a store to undef to indicate that the code is
>> unreachable (an unreachable instruction is a terminator instruction and
>> therefore inserting it would modify the CFG which instcombine is not
>> allowed to do).
>>
>> The guarantee instcombine offers is that the resulting code will have the
>> exact same behaviour as the input code for all cases where the input code
>> had well defined behaviour. Anything else is a bug.
>>
>> Nick
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140611/df07a248/attachment.html>