<div style="font-family: arial, helvetica, sans-serif"><font size="2"><div class="gmail_quote">On Mon, Jun 25, 2012 at 1:09 PM, Duncan Sands <span dir="ltr"><<a href="mailto:baldrick@free.fr" target="_blank">baldrick@free.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Nuno,<br>
<div class="im"><br>
> improve optimization of invoke instructions:<br>
>   - simplifycfg:  invoke undef/null -> unreachable<br>
<br>
</div>this part if OK.<br>
<div class="im"><br>
>   - instcombine:  invoke new  -> invoke expect(0, 0)  (an arbitrary NOOP intrinsic;  only done if the allocated memory is unused, of course)<br>
<br>
</div>What is this about?  If you are saying that malloc is nounwind, why aren't you<br>
marking it nounwind in SimplifyLibCalls.<br>
<br>
In any case, by removing the restriction that you can't do invoke on an<br>
intrinsic you are making a major (historically speaking change).  It should<br>
thus be done as part of a different commit, and accompanied with a bunch of<br>
tests checking that codegen doesn't crash if you try to codegen code that<br>
does invoke of an intrinsic.<br>
<br>
Finally, doing thus funky intrinsic thing seems a bizarre approach to me,<br>
there has to be a better way.<br></blockquote><div><br></div><div>In particular, I don't understand why we can't:</div><div><br></div><div>1) mark the invoke as nounwind, potentially using the same kind of logic you use to say that it can be removed entirely</div>
<div>2) SimplifyCFG transform from invoke to call</div><div>3) instcombine remove the call</div><div><br></div><div>There are a lot of other ways to phase-order-shuffle this problem if there is a specific pattern that needs to be simplified and is not simplified when relying on an instcombine run after simplifycfg has run...</div>
</div></font></div>