Duncan Sands
2012-Mar-02 15:05 UTC
[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. > > 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.
On Fri, 02 Mar 2012 16:05:17 +0100 Duncan Sands <baldrick at free.fr> 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. > > 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> > Ciao, Duncan. > _______________________________________________ > 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
James Molloy
2012-Mar-05 11:06 UTC
[LLVMdev] replace hardcoded function names by intrinsics
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 -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Hal Finkel Sent: 02 March 2012 15:32 To: Duncan Sands Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] replace hardcoded function names by intrinsics On Fri, 02 Mar 2012 16:05:17 +0100 Duncan Sands <baldrick at free.fr> 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. > > 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> > Ciao, Duncan. > _______________________________________________ > 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 _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev