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

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.

Best,
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140611/6ae19151/attachment.html>

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

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>