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

[Paul Vario]

That's a good point! The situation is that I am writing a few opt passes
that optimize some OpenCV functions. Those OpenCV functions should be well
tested and widely used, so they shouldn't contain weird cases like
self-referential phi's etc. But now, the output IR after -instcombine
contains "undef" values, I am trying to figure out whether this indicates
that there're bugs in my passes or is it still normal behavior that just
may happen when using -instcombine.


On Wed, Jun 11, 2014 at 4:07 PM, Nick Lewycky <nlewycky at google.com> wrote:

> 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/87624b9e/attachment.html>