Some questions on SelectionDAG

Hi, all

I am studying the ARM backend on SelectionDAG, I have some following questions:

  1. Each operator of SDNode in SelectionDAG is required to be defined by SDNodeISD::XXX,XXX,XXX in .td file, right?

But several operators are not defined in .td file, why? (e.g., ISD::BR_CC, ISD::CopyToReg, ISD::AssertSext)

  1. The MVT::glue value is used to ensure two nodes are scheduled together and in order.

In the other word, we can’t insert any instruction of them in the scheduling, is it correct?

  1. In the ARMISelLowering constructor, it sets the callback function with

setLoadExtAction(ISD::SEXTLOAD, MVT::i1, Promote);

My question is ARM don’t support MVT::i1 registerclass, why should it determine this operation with MVT::i1 value?

Can anyone tell me?

Thank you very much.

Best regards,

Zakk

Hi, all

I am studying the ARM backend on SelectionDAG, I have some following questions:

  1. Each operator of SDNode in SelectionDAG is required to be defined by SDNodeISD::XXX,XXX,XXX in .td file, right?

But several operators are not defined in .td file, why? (e.g., ISD::BR_CC, ISD::CopyToReg, ISD::AssertSext)

[Villmow, Micah] These are the standard nodes, please see the ISDOpcodes.h file in the include/llvm/CodeGen directory.

  1. The MVT::glue value is used to ensure two nodes are scheduled together and in order.

In the other word, we can’t insert any instruction of them in the scheduling, is it correct?

  1. In the ARMISelLowering constructor, it sets the callback function with

setLoadExtAction(ISD::SEXTLOAD, MVT::i1, Promote);

My question is ARM don’t support MVT::i1 registerclass, why should it determine this operation with MVT::i1 value?

[Villmow, Micah] Promote means the instruction that have a return value of that type extend to the next largest supported type.

Can anyone tell me?

Thank you very much.

Best regards,

Zakk

Hi Zakk,

3. In the ARMISelLowering constructor, it sets the callback function with

setLoadExtAction(ISD::SEXTLOAD, MVT::i1, Promote);

My question is ARM don’t support MVT::i1 registerclass, why should it determine
this operation with MVT::i1 value?

note that i1 is not a result type or operand type for SEXTLOAD; it is an
auxiliary value stored in a VALUETYPE node (IIRC). Thus the fact that i1
is not legal for this platform doesn't stop it from turning up, which is
why ARM needs to say what to do with it. You might wonder why you can get i1
here and not i2. That's because i1 is a simple value type, while i2 isn't.
The reason i1 is a simple value type is because you can play some tricks with
it that result in better code for booleans; x86 pretends to support extending
loads from i1 for example for this reason. Types like i2 are not interesting
in this way since they don't occur in practice, so they are left as extended
value types; the code generators zap all SEXTLOAD nodes that extend from an
extended value type automagically.

Ciao, Duncan.

preRA scheduling should keep them adjacent. But later MachineInstr passes, such as postRA scheduling may shuffle them around.

-Andy

Thanks for all replies, they have been very helpful!

Note: Sorry, i forgot to group reply…