[llvm-dev] mapping calls to exp() to expf opcode

Ryan Taylor via llvm-dev llvm-dev at lists.llvm.org
Thu Sep 1 10:44:01 PDT 2016


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>


More information about the llvm-dev mailing list