[LLVMdev] sincos optimization

[Redmond, Paul]

Hi,

I'm looking at http://llvm.org/bugs/show_bug.cgi?id=13204 which involves converting calls to sin and cos to sincos (when available)

Initially I thought about transforming calls to sinf/cosf to sincosf. However, I don't think this is a legal transformation given that a declaration for a function called sinf is not necessarily the standard library function.

Therefore it makes sense to transform intrinsic calls to sin and cos. One problem with this is that clang does not generate sin/cos intrinsics because they do not have the same semantics as the library functions.

What is the best way to approach this transformation?

(Also, experimentation shows that sincos is indeed faster than sin and cos)

paul







_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[David Given]

On 22/01/13 05:30, Redmond, Paul wrote:
[...]

> I'm looking at http://llvm.org/bugs/show_bug.cgi?id=13204 which involves converting calls to sin and cos to sincos (when available)
>
> Initially I thought about transforming calls to sinf/cosf to sincosf. However, I don't think this is a legal transformation given that a declaration for a function called sinf is not necessarily the standard library function.

I've actually just dealt with this --- standard library calls, including
sinf, *are* promoted to intrinsics if the compiler sees them (and are
then usually converted back to library calls again later). The list of
recognised names is here:

lib/Target/TargetLibraryInfo.cpp

The list of functions which are considered candidates for promotion is
in hasOptimizedCodeGen() in here:

include/llvm/Target/TargetLibraryInfo.h

...and the code that actually does it is here:

lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp

Look for SelectionDAGBuilder::visitUnaryFloatCall() and visitCall().

It appears that such functions are only promoted if they're declared
readnone, which provides some protection against overriding a standard
library function, but I haven't found anything that explicitly checks
for this yet.

Disclaimer: I learnt this yesterday...

--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "Of course, on a sufficiently small planet, 40 km/hr is, in fact,
│ sufficient to punt the elastic spherical cow into low orbit." ---
│ Brooks Moses on r.a.sf.c

[Redmond, Paul]

Hi David,

On 2013-01-22, at 5:59 AM, David Given wrote:

> ...and the code that actually does it is here:
>
> lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
>
> Look for SelectionDAGBuilder::visitUnaryFloatCall() and visitCall().
>
> It appears that such functions are only promoted if they're declared
> readnone, which provides some protection against overriding a standard
> library function, but I haven't found anything that explicitly checks
> for this yet.
>

Thanks for the tip. I am able to see sinf to FSIN generation when I compile with -ffast-math.

I don't have much experience with the selection dag but I feel like this transformation shouldn't be done at this level (it's more complicated than the transformations done by SelectionDAGCombine)

Would it make sense to move library call to intrinsic generation to the IR level?

[Owen Anderson]

On Jan 22, 2013, at 10:52 AM, "Redmond, Paul" <paul.r...@intel.com> wrote:
> Would it make sense to move library call to intrinsic generation to the IR level?

I think it would be a good idea. I'd like to see more of the libm-aware optimizations move out of DAGCombine and into IR level passes (InstCombine?). Translating library calls to intrinsics at the IR level makes that simpler.

--Owen