llvm dev - Mar 2012 - [LLVMdev] 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

On Fri, 02 Mar 2012 13:55:18 +0100
Jochen Wilhelmy <jochen.wilhelmy at googlemail.com> wrote:
> 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
> 
> -Jochen
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory

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.

>>
>> 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