type legalization/operation action

Dear there,

I have a target which is supporting the 32 bit operations natively. Right now,I want to make it support the 16 bits operations as well.
My initial thought is:
(1)
I can adding something like “ CCIfType< [i16], CCPromoteToType<i32>>”, to the CallingConv.td, then “all” the 16 bits operands will be automatically promoted to 32 bits, it will be all set.
but looks it is not the case.

(2)
Then I tried adding something like “ setOperationAction(ISD::ADD, MVT::i16, Promote)” to the IselLowering, it still failed to select the (i16 + i16)..

wondering which part I missed?

best

Kevin

Dear there,

I have a target which is supporting the 32 bit operations natively. Right now,I want to make it support the 16 bits operations as well.
My initial thought is:

Why do you need to do this? If you don't report having a 16-bit register type, all 16-bit operations should be appropriately promoted to 32-bit automatically?

-Matt

Dear there,

I have a target which is supporting the 32 bit operations natively. Right now,I want to make it support the 16 bits operations as well.

If you want to make 16-bit types legal you need to call:

addRegisterClass(MVT::i16, SomeRegisterClass) in your Target's TargetLowering
implementation.

My initial thought is:
(1)
I can adding something like “ CCIfType< [i16], CCPromoteToType<i32>>”, to the CallingConv.td, then “all” the 16 bits operands will be automatically promoted to 32 bits, it will be all set.
but looks it is not the case.

(2)
Then I tried adding something like “ setOperationAction(ISD::ADD, MVT::i16, Promote)” to the IselLowering, it still failed to select the (i16 + i16)..

Promoting ISD::ADD is not supported. Take a look in SelectionDAGLegalize::PromoteNode()
to see which opcodes can be promoted. You will either need to custome lower it or
properly handle it in the PromoteNode() function.

-Tom

Dear there,

I have a target which is supporting the 32 bit operations natively. Right now,I want to make it support the 16 bits operations as well.

If you want to make 16-bit types legal you need to call:

addRegisterClass(MVT::i16, SomeRegisterClass) in your Target's TargetLowering
implementation.

yeah., it is working.

My initial thought is:
(1)
I can adding something like “ CCIfType< [i16], CCPromoteToType<i32>>”, to the CallingConv.td, then “all” the 16 bits operands will be automatically promoted to 32 bits, it will be all set.
but looks it is not the case.

——————how to understand the “promote” in CallingConv.td?

(2)
Then I tried adding something like “ setOperationAction(ISD::ADD, MVT::i16, Promote)” to the IselLowering, it still failed to select the (i16 + i16)..

Promoting ISD::ADD is not supported. Take a look in SelectionDAGLegalize::PromoteNode()
to see which opcodes can be promoted. You will either need to custome lower it or
properly handle it in the PromoteNode() function.

thank you very much!

Think I run into this problem as well, it made me think the Promote is not working.

best

Dear there,

I have a target which is supporting the 32 bit operations natively. Right now,I want to make it support the 16 bits operations as well.
My initial thought is:

Why do you need to do this? If you don't report having a 16-bit register type, all 16-bit operations should be appropriately promoted to 32-bit automatically?

Thank you! I will discuss with team about this!

Best

Kevin

Adding back llvmdev.

Hi guys,
Talking about the following issue:
"


def: Pat< (i16 (add i16:$src1 i16:$src2)), ( ConvertToi16 ( IADDs (ZERO_EXTENDx i16:$src1) (ZERO_EXTENDx i16:$src2)))>

This pattern is emulating 16-bit addition using a 32-bit add.
If you have native 16-bit instructions then you shouldn't use this
pattern.

-Tom


Since I don’t have the native 16 bit operation support, I am going to “emulate” the operations using the corresponding 32 bits ops.
So I need the pattens like it is in above, or something like
"
  def: Pat< (i16 (add i16:$src1 i16:$src2)), ( trunc ( IADDs (zext i16:$src1) (zext i16:$src2)))>

of course, this pattern will not work, because the llvm node “trunc”, “zext” appears in the output patterns.
However, my “trunc”, “zext” is defined as patterns, so I don’t have something native supported like “TRUNCsr”, “ZEXTsr”.

How to solve those conflicts?

Best

Kevin

Hi guys,
Talking about the following issue:
"


def: Pat< (i16 (add i16:$src1 i16:$src2)), ( ConvertToi16 ( IADDs (ZERO_EXTENDx i16:$src1) (ZERO_EXTENDx i16:$src2)))>

This pattern is emulating 16-bit addition using a 32-bit add.
If you have native 16-bit instructions then you shouldn't use this
pattern.

-Tom


Since I don’t have the native 16 bit operation support, I am going to “emulate” the operations using the corresponding 32 bits ops.
So I need the pattens like it is in above, or something like
"
  def: Pat< (i16 (add i16:$src1 i16:$src2)), ( trunc ( IADDs (zext i16:$src1) (zext i16:$src2)))>

of course, this pattern will not work, because the llvm node “trunc”, “zext” appears in the output patterns.
However, my “trunc”, “zext” is defined as patterns, so I don’t have something native supported like “TRUNCsr”, “ZEXTsr”.

How to solve those conflicts?

Just don’t want to copy the stuff which is implementing the “zext”, “trunc” into my new pattern.

Hi guys,
Talking about the following issue:
"
>> “
>> def: Pat< (i16 (add i16:$src1 i16:$src2)), ( ConvertToi16 ( IADDs (ZERO_EXTENDx i16:$src1) (ZERO_EXTENDx i16:$src2)))>
>> “
>
> This pattern is emulating 16-bit addition using a 32-bit add.
> If you have native 16-bit instructions then you shouldn't use this
> pattern.
>
> -Tom


Since I don’t have the native 16 bit operation support, I am going to “emulate” the operations using the corresponding 32 bits ops.
So I need the pattens like it is in above, or something like
"
  def: Pat< (i16 (add i16:$src1 i16:$src2)), ( trunc ( IADDs (zext i16:$src1) (zext i16:$src2)))>

of course, this pattern will not work, because the llvm node “trunc”, “zext” appears in the output patterns.
However, my “trunc”, “zext” is defined as patterns, so I don’t have something native supported like “TRUNCsr”, “ZEXTsr”.

How to solve those conflicts?

If you don't support native i16 operations, then don't declare i16 as a
legal type and llvm will automatically promote these nodes using 32-bit ops.

Then you will only need patterns for 32-bit instructions.

-Tom