llvm dev - Jun 2014 - [LLVMdev] -instcombine introduces "undef" values to the IR.

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?

Best Regards,
Paul


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/3311e019/attachment.html>

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>

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>