<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 Aug 3, 2012, at 2:37 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Fri, Aug 3, 2012 at 2:26 PM, Bob Wilson <span dir="ltr"><<a href="mailto:bob.wilson@apple.com" target="_blank" class="cremed">bob.wilson@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Author: bwilson<br>
Date: Fri Aug 3 16:26:24 2012<br>
New Revision: 161263<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=161263&view=rev" target="_blank" class="cremed">http://llvm.org/viewvc/llvm-project?rev=161263&view=rev</a><br>
Log:<br>
Try to reduce the compile time impact of r161232.<br>
<br>
The previous change caused fast isel to not attempt handling any calls to<br>
builtin functions. That included things like "printf" and caused some<br>
noticable regressions in compile time. I wanted to avoid having fast isel<br>
keep a separate list of functions that had to be kept in sync with what the<br>
code in SelectionDAGBuilder.cpp was handling. I've resolved that here by<br>
moving the list into TargetLibraryInfo. This is somewhat redundant in<br>
SelectionDAGBuilder but it will ensure that we keep things consistent.<br></blockquote><div><br></div><div>So, perhaps this question just shows my lack of understanding of fast isel, but why not just teach fast isel to handle the builtins which need to be lowered to actual code? Wouldn't that both solve the problem (emitting library calls in fast isel) without hurting compile time by bailing to the selection dag as often?</div>
</div></div>
</blockquote><br></div><div>Yes, you could do that. Each target that supports fast isel (currently only x86 and ARM) would have to either implement the builtins or add the check that I put into the target-independent part. If someone wants to sink that check into the target-specific parts and start implementing fast isel support for some of the builtins, that would be fine. I doubt if it's worth the effort since these builtins should be fairly infrequent, now that I've limited the set of them.</div></body></html>