[llvm-commits] [llvm] r108639 - /llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp

Chris Lattner clattner at apple.com
Mon Jul 19 10:57:46 PDT 2010


On Jul 19, 2010, at 10:56 AM, Dale Johannesen wrote:

> 
> On Jul 18, 2010, at 1:12 PMPDT, Chris Lattner wrote:
> 
>> On Jul 18, 2010, at 1:02 PM, Owen Anderson wrote:
>> On Jul 18, 2010, at 12:52 PM, Chris Lattner wrote:
>>>> 
>>>> I would prefer for this to happen in InstCombiner::visitFPTrunc.  Both because we already have the infrastructure to do this there, but also because your code only handles the -fno-math-errno case.  Normal calls to libm sqrt should be transformed, not just llvm.sqrt.
>>> 
>>> Do we really want InstCombine assigning semantic value to random functions named sqrt()?  I understand SimplifyLibCalls doing this, since it implicitly assumes that we're using libc, but I'm wary of making InstCombine assume it.
>> 
>> Yes we do.  When/if we support -fno-builtin-sqrt, we will do this by adding a "not a builtin" function attribute, which optimizations like this should listen to.
> 
> This is adding the assumption that the source language is C-based,

No, this is just making the assumption that libm is in the address space.  This is not true for kernels, but is true for just about every user application, no matter what language it is written in.

> or otherwise has a sqrt (as Fortran).  So far this assumption has been quarantined in SimplifyLibCalls.

Yep, someone who cares should really implement -fno-builtin-foo support.

-Chris





More information about the llvm-commits mailing list