[llvm-commits] [llvm] r161263 - in /llvm/trunk: include/llvm/Target/TargetLibraryInfo.h lib/CodeGen/SelectionDAG/FastISel.cpp lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp

[Bob Wilson]

On Aug 3, 2012, at 2:37 PM, Chandler Carruth <chandlerc at google.com> wrote:

> On Fri, Aug 3, 2012 at 2:26 PM, Bob Wilson <bob.wilson at apple.com> wrote:
> Author: bwilson
> Date: Fri Aug  3 16:26:24 2012
> New Revision: 161263
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=161263&view=rev
> Log:
> Try to reduce the compile time impact of r161232.
> 
> The previous change caused fast isel to not attempt handling any calls to
> builtin functions.  That included things like "printf" and caused some
> noticable regressions in compile time.  I wanted to avoid having fast isel
> keep a separate list of functions that had to be kept in sync with what the
> code in SelectionDAGBuilder.cpp was handling.  I've resolved that here by
> moving the list into TargetLibraryInfo.  This is somewhat redundant in
> SelectionDAGBuilder but it will ensure that we keep things consistent.
> 
> 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?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120803/4490ab12/attachment.html>