<div dir="ltr">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.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 11, 2014 at 4:07 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 14:01, 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">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>


</blockquote><div><br></div></div><div>Well, yeah, but how do you know whether you got one of those corner cases?</div><div><br></div><div>There is a tool to detect likely bugs in .ll files, "opt -lint". Maybe that will help?</div>
<div class="">

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_extra"><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>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><font color="#888888">


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