[llvm-dev] Doubts

Tue Jun 7 09:37:18 PDT 2016

On Mon, Jun 6, 2016 at 8:32 AM, Nemanja Ivanovic via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> It is not a keyword. It is a node defined in
> include/llvm/Target/TargetSelectionDAG.td. You can likely find most of the
> definitions you're wondering about there.
> In terms of its purpose, perhaps someone can elaborate on that a bit more,
> but there is no corresponding ISD node for this and the way I look at it is
> that its purpose is to help Tbl-gen infer the result type of the node (in
> this case the "add" node). For example, you may have an instruction that
> adds two i32's and produces an i64 and then another one that produces an i32
> (I know this is kind of contrived in the case of addition, but you get the
> point). The DAGs would look identical except that the set node would have a
> different type.
> However, I may be wrong about this.

To elaborate a little: "set" is for more than just type inference.

It's the operator used to "set" registers (the first operands) to
given values (the last operand, usually a DAG).
It's a special node that doesn't map to an ISD opcode because it
represents something that isn't in the SelectionDAG: instruction-level
(as opposed to block live-ins/-outs) virtual registers.

Another way to think about it is that, roughly, each SDValue maps to a
vreg, and "set" does the association between SDValues produced by an
SDNode, and vregs produced by the selected instruction.

It can set multiple registers (if the last operand produces multiple
values).  For instance, X86 has things like "[(set GR32:$dst, EFLAGS,
(X86add_flag GR32:$src1, GR32:$src2))]"

Patterns can't have a root node with a non-void return, because, how
would we decide where the return value goes?
So, you can basically write two kinds of patterns:
- (set <register class>:$dst, <operand>)
- (<void-typed operator> <operands>)

"store" is really just the most common case of the second kind: since
it's an operator that doesn't produce any value and has type "void",
it can be used to form a root node in the pattern DAG.

The third most common kind of root operator is probably void-returning
intrinsics (look for "[(int_").
There's also another special operator, "implicit", which is necessary
because a pattern for an instruction X should define all registers
that X defines, even if the definition isn't something we're matching
in the SelectionDAG (that's what makes it implicit).

HTH,
-Ahmed

> Of course, "store" is quite different. That is a full fledged node and has
> fairly straightforward semantics - it's a store node. So for example a DAG
> that looks like:
> (store i64:$src, addr:$dst)
> actually says store the 64-bit integer $src at address $dst.
>
> Nemanja
>
> On Mon, Jun 6, 2016 at 5:16 PM, Pedro Lopes <pedro.fraiao at gmail.com> wrote:
>>
>> Thanks, indeed it was on the LegalizeDAG.cpp and the information proved
>> very useful.
>>
>> I also realized that the customization, promotion or expansion will occur
>> whenever any operand, with the same type as the type specified on the second
>> argument (MVT) of setOperationAction function, appears. (Correct me if I'm
>> wrong).
>>
>> The second doubt I have regards instruction matching.
>>
>> When I define a pattern such as:
>> [(set i32:$dst, (add (mul i32:$src1, i32:$src2), i32:$src3))]>
>>
>> What is the meaning of the word "set" or "store" which appear quite often?
>> From what I can understand this pattern is only interest in an add node
>> with a mul node as one operator and an immediate as the other.
>> Does the "set" (keyword?) translates to an output of the add node, or just
>> another node?
>>
>> Thanks,
>> Patosga
>>
>> 2016-06-06 6:22 GMT+01:00 Nemanja Ivanovic <nemanja.i.ibm at gmail.com>:
>>>
>>>
>>> Hi Patosga,
>>> you can control what type the operands are promoted to as follows:
>>> AddPromotedToType (ISD::ADD, MVT::i1, MVT::i64);
>>>
>>> For the "Expand" case, I believe you'll find what you're looking for in
>>> the file:
>>> lib/CodeGen/SelectionDAG/LegalizeDAG.cpp
>>> and function SelectionDAGLegalize::ExpandNode(), but if I'm wrong here
>>> perhaps others can correct me.
>>>
>>> Finally, MVT::f32 just states that the operand is a 32-bit single
>>> precision floating point type.
>>>
>>> Nemanja
>>>
>>> On Sun, Jun 5, 2016 at 11:05 PM, Pedro Lopes via llvm-dev
>>> <llvm-dev at lists.llvm.org> wrote:
>>>>
>>>> Sorry, glad I'm in the right place.
>>>> Before I start, I want to state that I'm a beginer and I'm trying to
>>>> develop a backend by adapting an existent target to my platform.
>>>>
>>>> My first doubt is about the SelectionDAG and the TargetLowering class.
>>>> When I use, for example:
>>>> setOperationAction(ISD::ADD, MVT::i1, Promote);
>>>>
>>>> Is it correct to say that I'm promoting any operand used by the ISD::ADD
>>>> node to a larger type? If so, what would that value type be?
>>>>
>>>> If I use the same function with the expand as the third argument like
>>>> below:
>>>> setOperationAction(ISD::FSIN, MVT::f32, Expand);
>>>> What will the expansion look like, since I don´t provide any custom
>>>> implementation of the node? Also, what is the meaning of the MVT::f32 in
>>>> this case?
>>>>
>>>> Thanks,
>>>> Patosga
>>>>
>>>> 2016-06-05 19:16 GMT+01:00 Pierre Gagelin <Pierre.Gagelin at myport.ac.uk>:
>>>>>
>>>>> Hi Patosga,
>>>>>
>>>>> You are on the right place to ask your questions and get help!
>>>>>
>>>>> Try to be more specific with your problem. We need some details to help
>>>>> you =)
>>>>>
>>>>> Pierre
>>>>>
>>>>> On 5 June 2016 at 18:12, via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>>>>>
>>>>>> Hello sir,
>>>>>>
>>>>>> I'm having some problems understading how llvm works. I'm following a
>>>>>> concrete example and visualizing the DAG and the .s output and some stuff
>>>>>> doesn´t seem to match.
>>>>>>
>>>>>> I sorry to bother you but I don´t know where I can expose my doubts
>>>>>> and I wonder if you could redirect me to some discussion place where someone
>>>>>> might help me.
>>>>>>
>>>>>> Thanks,
>>>>>> Patosga
>>>>>>
>>>>>> _____________________________________
>>>>>> Sent from http://llvm.1065342.n5.nabble.com
>>>>>>
>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> llvm-dev at lists.llvm.org
>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>
>>
>>
>>
>> --
>> Cumprimentos,
>> José Pedro Lopes
>> ------------------------------------
>> Best Regards,
>> José Pedro Lopes
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>