Phil Tomson via llvm-dev
2016-Aug-31 22:40 UTC
[llvm-dev] mapping calls to exp() to expf opcode
We've got both an sqrtf and an expf opcode in our architecture. If I call sqrt() on the C side, I see the sqrtf opcode show up in the generated assembly. However, if I call exp() on the C side, I don't see the expf opcode show up on the generated assembly, I see a call to an exp function from libm. Here's what we've got in our TargetInstrinfo.td file for both of these instructions: def SQRTF64 : Other2ROp< 0b0001101, "sqrtF", fsqrt, OpInfo_F64, II_ELEMF3 >; def SQRTF32 : Other2ROp< 0b0001101, "sqrtF", fsqrt, OpInfo_F32, II_ELEMF1 >; def EXPF64 : Other2ROp< 0b0001010, "expF", fexp2, OpInfo_F64, II_ELEMF3 >; def EXPF32 : Other2ROp< 0b0001010, "expF", fexp2, OpInfo_F32, II_ELEMF1 >; ..essentially the same kind of definition for both SQRTF and EXPF, but for the latter I don't see expf opcodes being generated. Any idea what might be missing for exp? Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160831/65bd0eac/attachment.html>
Ryan Taylor via llvm-dev
2016-Sep-01 17:44 UTC
[llvm-dev] mapping calls to exp() to expf opcode
Phil, Are you seeing the fexp2 SDNode with -view-legalize-dags and then a call with -view-dag-combine2-dags? In XXXISelLowering.cpp please try to explicitly make fexp2 'legal', ie "setOperationAction(ISD::FEXP2, MVT::f32, Legal); setOperationAction(ISD::FEXP2, MVT::f64, Legal)". This worked for me, I am now no longer getting a call and am now getting an ISEL error (not matching SDNode in tablegen, which is what you want since it's legal on your target). I find this confusing since the default is suppose to be 'Legal' from my understanding but LLVM is not always consistent this way, the community has decided to do things 'this way' or 'that way' depending on 'what's common' sometimes. Thanks, -Ryan On Wed, Aug 31, 2016 at 6:40 PM, Phil Tomson via llvm-dev < llvm-dev at lists.llvm.org> wrote:> We've got both an sqrtf and an expf opcode in our architecture. If I call > sqrt() on the C side, I see the sqrtf opcode show up in the generated > assembly. However, if I call exp() on the C side, I don't see the expf > opcode show up on the generated assembly, I see a call to an exp function > from libm. > > Here's what we've got in our TargetInstrinfo.td file for both of these > instructions: > def SQRTF64 : Other2ROp< 0b0001101, "sqrtF", fsqrt, OpInfo_F64, II_ELEMF3 > >; > def SQRTF32 : Other2ROp< 0b0001101, "sqrtF", fsqrt, OpInfo_F32, II_ELEMF1 > >; > > def EXPF64 : Other2ROp< 0b0001010, "expF", fexp2, OpInfo_F64, II_ELEMF3 > >; > def EXPF32 : Other2ROp< 0b0001010, "expF", fexp2, OpInfo_F32, II_ELEMF1 > >; > > > ..essentially the same kind of definition for both SQRTF and EXPF, but for > the latter I don't see expf opcodes being generated. > > Any idea what might be missing for exp? > > Phil > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160901/603ecfb9/attachment.html>
Phil Tomson via llvm-dev
2016-Sep-02 21:10 UTC
[llvm-dev] mapping calls to exp() to expf opcode
Both of them have 'Legal' (as well as sin and cos), but that doesn't make any difference - I still don't see exp, exp2, sin or cos show up as opcodes in the assembly. For some reason calls to sqrt show up as opcodes (sqrtf) - I'm puzzled as to what is different with sqrt. Phil On Thu, Sep 1, 2016 at 10:44 AM, Ryan Taylor <ryta1203 at gmail.com> wrote:> Phil, > > Are you seeing the fexp2 SDNode with -view-legalize-dags and then a call > with -view-dag-combine2-dags? > > In XXXISelLowering.cpp please try to explicitly make fexp2 'legal', ie > "setOperationAction(ISD::FEXP2, MVT::f32, Legal); > setOperationAction(ISD::FEXP2, MVT::f64, Legal)". This worked for me, I am > now no longer getting a call and am now getting an ISEL error (not matching > SDNode in tablegen, which is what you want since it's legal on your target). > > I find this confusing since the default is suppose to be 'Legal' from my > understanding but LLVM is not always consistent this way, the community has > decided to do things 'this way' or 'that way' depending on 'what's common' > sometimes. > > Thanks, > > -Ryan > > On Wed, Aug 31, 2016 at 6:40 PM, Phil Tomson via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> We've got both an sqrtf and an expf opcode in our architecture. If I call >> sqrt() on the C side, I see the sqrtf opcode show up in the generated >> assembly. However, if I call exp() on the C side, I don't see the expf >> opcode show up on the generated assembly, I see a call to an exp function >> from libm. >> >> Here's what we've got in our TargetInstrinfo.td file for both of these >> instructions: >> def SQRTF64 : Other2ROp< 0b0001101, "sqrtF", fsqrt, OpInfo_F64, II_ELEMF3 >> >; >> def SQRTF32 : Other2ROp< 0b0001101, "sqrtF", fsqrt, OpInfo_F32, II_ELEMF1 >> >; >> >> def EXPF64 : Other2ROp< 0b0001010, "expF", fexp2, OpInfo_F64, II_ELEMF3 >> >; >> def EXPF32 : Other2ROp< 0b0001010, "expF", fexp2, OpInfo_F32, II_ELEMF1 >> >; >> >> >> ..essentially the same kind of definition for both SQRTF and EXPF, but >> for the latter I don't see expf opcodes being generated. >> >> Any idea what might be missing for exp? >> >> Phil >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160902/0b3e2346/attachment.html>
Maybe Matching Threads
- Expanding a PseudoOp and accessing the DAG
- Expanding a PseudoOp and accessing the DAG
- [LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
- prevent conversion to factors in aggregate?
- R function for Probabilities for the (standard) normal distribution