replace hardcoded function names by intrinsics

Hi!

in the llvm code there are several places with hardcoded function names for
e.g. sin, sinf, sqrt, sqrtf etc., namely
ConstantFolding.cpp
InlineCost.cpp
SelectionDAGBuilder.cpp
IntrinsicLowering.cpp
TargetLowering.cpp

my question is: wouldn't it be beneficial to use intrinsics for this? for example a c/c++
frontend (clang) could translate the function calls to intrinsics and then in a very late
step (IntrinsicLowering.cpp?) translate it back to function calls.
an opencl frontend then could use the intrinsics on vector types and ConstantFolding.cpp
would work on sin/cos of vector types. currently the intrinsics for sin/cos are missing in
ConstantFolding.
To summarize, using only intrinsics would reduce complexity and increase flexibility as
vector types are supported.

-Jochen

Hi!

in the llvm code there are several places with hardcoded function
names for e.g. sin, sinf, sqrt, sqrtf etc., namely
ConstantFolding.cpp
InlineCost.cpp
SelectionDAGBuilder.cpp
IntrinsicLowering.cpp
TargetLowering.cpp

my question is: wouldn't it be beneficial to use intrinsics for this?
for example a c/c++
frontend (clang) could translate the function calls to intrinsics and
then in a very late
step (IntrinsicLowering.cpp?) translate it back to function calls.
an opencl frontend then could use the intrinsics on vector types and
ConstantFolding.cpp
would work on sin/cos of vector types. currently the intrinsics for
sin/cos are missing in
ConstantFolding.
To summarize, using only intrinsics would reduce complexity and
increase flexibility as
vector types are supported.

I also think that this is a good idea.

-Hal

Hi,

in the llvm code there are several places with hardcoded function
names for e.g. sin, sinf, sqrt, sqrtf etc., namely
ConstantFolding.cpp
InlineCost.cpp
SelectionDAGBuilder.cpp
IntrinsicLowering.cpp
TargetLowering.cpp

my question is: wouldn't it be beneficial to use intrinsics for this?
for example a c/c++
frontend (clang) could translate the function calls to intrinsics and
then in a very late
step (IntrinsicLowering.cpp?) translate it back to function calls.
an opencl frontend then could use the intrinsics on vector types and
ConstantFolding.cpp
would work on sin/cos of vector types. currently the intrinsics for
sin/cos are missing in
ConstantFolding.
To summarize, using only intrinsics would reduce complexity and
increase flexibility as
vector types are supported.

I also think that this is a good idea.

intrinsics don't have the same semantics as the library functions. For example
they don't set errno and in general they are less accurate. Thus you can't turn
every use of eg sqrt into an intrinsic. However you will still want to constant
fold instances of sqrt that weren't turned into an intrinsic, and thus all those
names will still need to exist in constant fold etc, so this change wouldn't buy
you much.

Ciao, Duncan.

Hi,

>> in the llvm code there are several places with hardcoded function
>> names for e.g. sin, sinf, sqrt, sqrtf etc., namely
>> ConstantFolding.cpp
>> InlineCost.cpp
>> SelectionDAGBuilder.cpp
>> IntrinsicLowering.cpp
>> TargetLowering.cpp
>>
>> my question is: wouldn't it be beneficial to use intrinsics for
>> this? for example a c/c++
>> frontend (clang) could translate the function calls to intrinsics
>> and then in a very late
>> step (IntrinsicLowering.cpp?) translate it back to function calls.
>> an opencl frontend then could use the intrinsics on vector types
>> and ConstantFolding.cpp
>> would work on sin/cos of vector types. currently the intrinsics for
>> sin/cos are missing in
>> ConstantFolding.
>> To summarize, using only intrinsics would reduce complexity and
>> increase flexibility as
>> vector types are supported.
>
> I also think that this is a good idea.

intrinsics don't have the same semantics as the library functions.
For example they don't set errno and in general they are less
accurate. Thus you can't turn every use of eg sqrt into an
intrinsic. However you will still want to constant fold instances of
sqrt that weren't turned into an intrinsic, and thus all those names
will still need to exist in constant fold etc, so this change
wouldn't buy you much.

In some cases, this will depend on how these things are lowered, if
bounds can be put on the input ranges, etc. Otherwise, I think this is
a "fast math" kind of optimization. Do you disagree?

Would it be useful, for this purpose, to have an
(inter-procedural) analysis pass, or some annotation-driven mechanism,
or both, to mark errno as "dead" so we don't have to worry about this
kind of thing if it is not necessary?

-Hal

To summarize, using only intrinsics would reduce complexity and
increase flexibility as
vector types are supported.

I also think that this is a good idea.

the first step could be doing it for sin, cos and sqrt for which intrinsics
already exist.

-Jochen

Hi!

The main problem I currently see is that frontend/language specific
assumptions are hardcoded inside the constant folding, namely
that a function named sin calculates the sine. languages with some
kind of name mangling don't benefit from this. so another solution
would be making the constant folding extendable, i.e. that a table
of function names and evaluators can be passed in from the outside.
this way the c-specific stuff is removed from llvm and other functions
like e.g. convert_int_rte() of opencl could be constant folded too.
maybe this table can be per llvmContext so that InlineCost.cpp can
accessed it too.

-Jochen

Hi,

Would it be useful, for this purpose, to have an
(inter-procedural) analysis pass, or some annotation-driven mechanism,
or both, to mark errno as "dead" so we don't have to worry about this
kind of thing if it is not necessary?

This is currently done by marking the declaration of @sinf and friends to be
"readnone". I recently fixed a bug where log2 and exp2 did not have that
readnone check, so it can be quite temperamental..

Cheers,

James