<div dir="ltr">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?<div>
<br></div><div>Best Regards,</div><div>Paul</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 11, 2014 at 3:09 PM, Nick Lewycky <span dir="ltr"><<a href="mailto:nlewycky@google.com" target="_blank">nlewycky@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="">On 11 June 2014 12:26, Paul Vario <span dir="ltr"><<a href="mailto:paul.paul.mit@gmail.com" target="_blank">paul.paul.mit@gmail.com</a>></span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Fellows,<div><br></div><div>     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.</div>



</div></blockquote><div><br></div></div><div>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).</div>



<div><br></div><div>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.</div>
<span class="HOEnZb"><font color="#888888">


<div><br></div><div>Nick</div><div><br></div></font></span></div></div></div>
</blockquote></div><br></div>