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

[Paul Vario]

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>