llvm dev - Jan 2013 - [LLVMdev] sincos optimization

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130122/c7f54553/attachment.sig>

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?

paul