llvm dev - Aug 2016 - 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>

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>

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>