<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 18, 2012, at 7:24 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 18, 2012 at 5:42 PM, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank" class="cremed">silvas@purdue.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is this substantively different than just inlining __udivsi3?<br></blockquote><div><br></div><div>I'd particularly like to understand this design choice.</div>
<div><br></div><div>It would seem better to emit a single separate function (appropriately mangled and with appropriate linkage to never conflict with anything) and allow the existing inliner to manage when the call should be present. Then the utility would ensure that emission took place and produce a call to it. Maybe there are reasons this won't work well in practice, but those should at least be discussed.</div></div></div></blockquote><br></div><div>The simple answer is that this is intended for use very late in the optimization pipeline, after inlining has been done already. If it could be done in legalization, it would be. But given that it can't, we want to perform the substitution as late in the IR pipeline as we can. Given that, materializing a copy of __udivsi3 and force-inlining it would just be wasteful of compile time.</div><div><br></div><div>--Owen</div></body></html>