llvm dev - Sep 2011 - [LLVMdev] 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
SDNode<ISD::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)



2. 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?



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?



Can anyone tell me?

Thank you very much.




Best regards,

Zakk
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110902/886c3b23/attachment.html>

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Zakk
Sent: Friday, September 02, 2011 3:15 AM
To: llvmdev
Subject: [LLVMdev] 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
SDNode<ISD::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.

2. 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?

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?
[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



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110902/ad83b654/attachment.html>

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.

On Sep 2, 2011, at 3:14 AM, Zakk wrote:
> 2. 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?
> 
preRA scheduling should keep them adjacent. But later MachineInstr passes, such
as postRA scheduling may shuffle them around.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110906/c7cfc4c6/attachment.html>

Thanks for all replies, they have been very helpful!

Note: Sorry, i forgot to group reply....

---------- Forwarded message ----------
From: Duncan Sands <baldrick at free.fr>
Date: 2011/9/4
Subject: Re: [LLVMdev] Some questions on SelectionDAG
To: Zakk <zakk0610 at gmail.com>


Hi Zak,


 Therefore, after the LegalizeType phase, maybe SelectionDAG
have
> unsupported
> type node?
>
no.  As I tried to explain, there is no node with type MVT:i1 after type
legalization.  There is a VALUETYPE node with type MVT::Other that contains
the type MVT::i1 as an auxiliary datum.


 My confusion is the unsupported type( like MVT::i1) have
converted
> to supported type in LegalizeTypes phase,
>
They have.


 but the setXXXXAction
> callbacks(like setLoadExtAction(ISD::**SEXTLOAD, MVT::i1, Promote);)
>
Here MVT::i1 is not referring to the type of any node, it is referring
to the extra data held in the VALUETYPE node argument of the SEXTLOAD
node.


 are used to eliminate any operations that are
unsupported
> on the target in Legalize phase after then LegalizeType phase.
>
(http://llvm.org/docs/**CodeGenerator.html#**selectiondag_legalize<http://llvm.org/docs/CodeGenerator.html#selectiondag_legalize>
> )
> Do I misunderstand any concept here?
>
Ciao, Duncan.

>
> Best regards,
>
> Zakk
>
>
>
>
> 2011/9/3 Duncan Sands <baldrick at free.fr <mailto:baldrick at
free.fr>>
>
>
>    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.
>    ______________________________**_________________
>    LLVM Developers mailing list
>    LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
> http://llvm.cs.uiuc.edu
>
>   
http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>
>
>
>
>
>
>


-- 
Best regards,

Zakk
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110907/3f1045a1/attachment.html>