Rail Shafigulin via llvm-dev
2016-Jan-29  19:39 UTC
[llvm-dev] Specifying DAG patterns in the instruction
On Thu, Jan 28, 2016 at 8:34 PM, Dylan McKay <dylanmckay34 at gmail.com> wrote:> Try visualising the DAG like this. > > ``` > ---- GPR:$rA > / > set GPR:$rd ---- add > \ > ---- GPR:$rB > ``` > > Each instruction forms a DAG with its operands being subnodes. > > The core instruction selection logic just looks for the pattern `(set > GPR:$rd, (add GPR:$rA, GPR:$rB))`. It then becomes a simple substitution. > This is a DAG because there all nodes are directed and acyclic. >Am I correct in my understanding that each node can either be a register or of type SDNode defined in TargetSelectionDAG.td?> On Thu, Jan 28, 2016 at 7:33 PM, Rail Shafigulin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I'm confused about how to specify DAG patterns for a given instruction >> >> Here is an example for my target >> >> class ALU1_RR<bits<4> subOp, string asmstr, SDNode OpNode> >> : ALU_RR<subOp, asmstr, >> [(set GPR:$rD, (OpNode (i32 GPR:$rA), (i32 GPR:$rB)))]>; >> >> def ADD : ALU1_RR<0x0, "l.add", add>; >> >> The set operation simply creates a list. The add operation creates a >> union. So at the end [(set GPR:$rD, (OpNode (i32 GPR:$rA), (i32 >> GPR:$rB)))] becomes a just a regular set. How come this is a DAG? I feel >> like I'm missing something. Would anyone be able to help with the >> explanation? >> >> -- >> Rail Shafigulin >> Software Engineer >> Esencia Technologies >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >-- Rail Shafigulin Software Engineer Esencia Technologies -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160129/b501d226/attachment.html>
Rail Shafigulin via llvm-dev
2016-Jan-29  19:54 UTC
[llvm-dev] Specifying DAG patterns in the instruction
On Fri, Jan 29, 2016 at 11:39 AM, Rail Shafigulin <rail at esenciatech.com> wrote:> > > On Thu, Jan 28, 2016 at 8:34 PM, Dylan McKay <dylanmckay34 at gmail.com> > wrote: > >> Try visualising the DAG like this. >> >> ``` >> ---- GPR:$rA >> / >> set GPR:$rd ---- add >> \ >> ---- GPR:$rB >> ``` >> >> Each instruction forms a DAG with its operands being subnodes. >> >> The core instruction selection logic just looks for the pattern `(set >> GPR:$rd, (add GPR:$rA, GPR:$rB))`. It then becomes a simple substitution. >> This is a DAG because there all nodes are directed and acyclic. >> > > > Am I correct in my understanding that each node can either be a register > or of type SDNode defined in TargetSelectionDAG.td? >I should clarify. What I'm confused about is how exactly the DAG is defined. Here is what is says on llvm.org/docs/TableGen/LangIntro.html (DEF a, b)a dag value. The first element is required to be a record definition, the remaining elements in the list may be arbitrary other values, including nested `dag‘ values.What is meant by a record definition? Is it a definition of type SDNode which are defined in TargetSelectionDAG.td? What exactly does (DEF, a, b) represent in the graph? Is it --------- a / DEF \ ----------b or --------a / -------- DEF \ -------b> > >> On Thu, Jan 28, 2016 at 7:33 PM, Rail Shafigulin via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> I'm confused about how to specify DAG patterns for a given instruction >>> >>> Here is an example for my target >>> >>> class ALU1_RR<bits<4> subOp, string asmstr, SDNode OpNode> >>> : ALU_RR<subOp, asmstr, >>> [(set GPR:$rD, (OpNode (i32 GPR:$rA), (i32 GPR:$rB)))]>; >>> >>> def ADD : ALU1_RR<0x0, "l.add", add>; >>> >>> The set operation simply creates a list. The add operation creates a >>> union. So at the end [(set GPR:$rD, (OpNode (i32 GPR:$rA), (i32 >>> GPR:$rB)))] becomes a just a regular set. How come this is a DAG? I feel >>> like I'm missing something. Would anyone be able to help with the >>> explanation? >>> >>> -- >>> Rail Shafigulin >>> Software Engineer >>> Esencia Technologies >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> >> > > > -- > Rail Shafigulin > Software Engineer > Esencia Technologies >-- Rail Shafigulin Software Engineer Esencia Technologies -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160129/9e0ef20d/attachment.html>
Dylan McKay via llvm-dev
2016-Jan-31  01:32 UTC
[llvm-dev] Specifying DAG patterns in the instruction
TableGen, as a DSL language, is made up of records. Every def corresponds
to a record. For example, TableGen has a class Register, and your backend
will define records by def GPR8 : Register<...>. You are correct in saying
that the record definition is one of the SDNode values. These correspond
1:1 to llvm::ISD::NodeType
<http://llvm.org/docs/doxygen/html/namespacellvm_1_1ISD.html#a22ea9cec080dd5f4f47ba234c2f59110>
.
(DEF a, b) corresponds to
    --------- a
   /
DEF
   \
    ----------b
A more complicated example, regarding that a and b themselves can be nested
DAGs.
                     a
                   /
     --------- add
    /              \
   /                 b
DEF
   \                 c
    \              /
     ---------- sub
                   \
                    d
And so on and so fourth.
On Sat, Jan 30, 2016 at 8:54 AM, Rail Shafigulin <rail at esenciatech.com>
wrote:
>
>
> On Fri, Jan 29, 2016 at 11:39 AM, Rail Shafigulin <rail at
esenciatech.com>
> wrote:
>
>>
>>
>> On Thu, Jan 28, 2016 at 8:34 PM, Dylan McKay <dylanmckay34 at
gmail.com>
>> wrote:
>>
>>> Try visualising the DAG like this.
>>>
>>> ```
>>>                        ---- GPR:$rA
>>>                       /
>>> set GPR:$rd  ---- add
>>>                       \
>>>                        ---- GPR:$rB
>>> ```
>>>
>>> Each instruction forms a DAG with its operands being subnodes.
>>>
>>> The core instruction selection logic just looks for the pattern
`(set
>>> GPR:$rd, (add GPR:$rA, GPR:$rB))`. It then becomes a simple
substitution.
>>> This is a DAG because there all nodes are directed and acyclic.
>>>
>>
>>
>> Am I correct in my understanding that each node can either be a
register
>> or of type SDNode defined in TargetSelectionDAG.td?
>>
>
> I should clarify. What I'm confused about is how exactly the DAG is
> defined. Here is what is says on llvm.org/docs/TableGen/LangIntro.html
> (DEF a, b)a dag value. The first element is required to be a record
> definition, the remaining elements in the list may be arbitrary other
> values, including nested `dag‘ values.What is meant by a record
> definition? Is it a definition of type SDNode which are defined in
> TargetSelectionDAG.td?
> What exactly does (DEF, a, b) represent in the graph?
>
> Is it
>
>         --------- a
>        /
> DEF
>        \
>         ----------b
>
> or
>
>  --------a
> /
> -------- DEF
> \
>   -------b
>
>
>
>
>>
>>
>>> On Thu, Jan 28, 2016 at 7:33 PM, Rail Shafigulin via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> I'm confused about how to specify DAG patterns for a given
instruction
>>>>
>>>> Here is an example for my target
>>>>
>>>> class ALU1_RR<bits<4> subOp, string asmstr, SDNode
OpNode>
>>>>   : ALU_RR<subOp, asmstr,
>>>>            [(set GPR:$rD, (OpNode (i32 GPR:$rA), (i32
GPR:$rB)))]>;
>>>>
>>>> def ADD  : ALU1_RR<0x0, "l.add", add>;
>>>>
>>>> The set operation simply creates a list. The add operation
creates a
>>>> union. So at the end  [(set GPR:$rD, (OpNode (i32 GPR:$rA),
(i32
>>>> GPR:$rB)))] becomes a just a regular set. How come this is a
DAG? I feel
>>>> like I'm missing something. Would anyone be able to help
with the
>>>> explanation?
>>>>
>>>> --
>>>> Rail Shafigulin
>>>> Software Engineer
>>>> Esencia Technologies
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>>
>>>
>>
>>
>> --
>> Rail Shafigulin
>> Software Engineer
>> Esencia Technologies
>>
>
>
>
> --
> Rail Shafigulin
> Software Engineer
> Esencia Technologies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160131/15614bd8/attachment.html>