llvm dev - Oct 2020 - Manipulating DAGs in TableGen

On Tue, Oct 13, 2020 at 10:47 AM Madhur Amilkanthwar
<madhur13490 at gmail.com> wrote:
> What do you guys think about the below enhancements?
>
> 5. !getdagrestype(dag [, index]) - Returns type of result value. If the DAG
computes multiple values then return type of 'index'th result.
>
> 6. !setdagrestype(dag target_dag, type T [, index]) - Set return type of
target_dag to T. Use of 'index' is as in 5.(Coupled with the existing
(or enhanced?) foreach construct we can construct multiple DAGs with different
return types.)
>
> .7 !setdagchild(dag target_dag, dag new_dag, index) - Set child
'index' numbered of target_dag to new_dag. I think this is more or less
similar to 3 you suggested but I feel it is more convenient and concise.
>
> 8. !setdagchildcond(dag target_dag, dag new_dag, index, {C++ code}) -
Similar to 7 above but do it only if the C++ code returns true. This is useful
to check if the result type of `new_dag` and that of the operand type of
'index' child of 'target_dag' are compatible. Users can define
compatibility using C++ code. For example, it is okay to set dag even if there
is mismatch between signedness of types.
All of these sound like operations that are specific to TableGen
backend interpretations of what a DAG means. This discussion is about
!ops which are a part of the TableGen frontend, so I don't think any
of these apply here.

Cheers,
Nicolai



>
>
>
> On Mon, Oct 12, 2020 at 11:31 PM Paul C. Anagnostopoulos via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>>
>> I understood that the name is a matching tag for the operand and not
its name (as in named macro or function arguments). However, I was assuming that
the names in any one DAG node had to be unique and so could serve as selectors
for operands. But a quick investigation shows that I was wrong: names can be
duplicated in the same node.
>>
>> So DAG indexes are integers only.
>>
>>
>> At 10/12/2020 01:46 PM, Nicolai Hähnle wrote:
>> >On Mon, Oct 12, 2020 at 7:37 PM Paul C. Anagnostopoulos
>> ><paul at windfall.com> wrote:
>> >> I included the ability to get/set an operand by name because I
thought it would be easier to copy+modify an existing DAG by specifying the name
of the operand you want to replace rather than having to remember its position.
For example, if you want to replace the first source, isn't it easier to
specify $src than remember it's the second operand?
>> >
>> >My point is precisely that the $names don't work that way. Your
>> >reasoning would be valid if the $names were function/operator
argument
>> >names, like in programming languages where you can pass function
>> >arguments based on their order but also by naming them (e.g.
>> >"functionName(argName=x, otherArgName=y)"). However, this
is _not_ how
>> >$names work!
>> >
>> >Their most prominent application is for instruction selection
pattern
>> >matching, e.g. taken at random from AMDGPU/SOPInstructions.td:
>> >
>> >def : GCNPat <
>> >  (i32 (smax i32:$x, (i32 (ineg i32:$x)))),
>> >  (S_ABS_I32 SReg_32:$x)
>> >>;
>> >
>> >The $x is _not_ the name of the argument to smax, ineg, or
S_ABS_I32.
>> >For example, if you look at how S_ABS_I32 is defined, you'll
see that
>> >its input operand is called $src0.
>> >
>> >Instead, the name allows us to tie three locations in the DAG
together
>> >for purposes of pattern matching. The name is only meaningful in
the
>> >context of this pattern. You could substitute $x by $y or $whatever
>> >without changing the meaning of the DAG.
>> >
>> >That the name is the name of an operator argument is an
understandable
>> >misunderstanding, but it _is_ a misunderstanding. If you were to
add
>> >that particular feature, you would encourage this misunderstanding
>> >even more.
>>
>>
>> ----------------------------------------------------------------
>> Windfall               Paul C. Anagnostopoulos
>>       ----------------------------------------------------------
>>    Software            978 369-0839
>>                              www.windfall.com
>> ----------------------------------------------------------------
>> My life has been filled with calamities,
>> some of which actually happened.
>> ---Mark Twain
>>
>> Guga 'mzimba, sala 'nhliziyo
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> --
> Disclaimer: Views, concerns, thoughts, questions, ideas expressed in this
mail are of my own and my employer has no take in it.
> Thank You.
> Madhur D. Amilkanthwar
>

-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.

Nicolai:

If we have two operators to get and set DAG operator/operands, does it make
sense to add to more operators to get/set the $names of operands? They would
still specify the operand by integer index.

At 10/13/2020 10:16 AM, Nicolai Hähnle wrote:
>On Tue, Oct 13, 2020 at 10:47 AM Madhur Amilkanthwar
><madhur13490 at gmail.com> wrote:
>> What do you guys think about the below enhancements?
>>
>> 5. !getdagrestype(dag [, index]) - Returns type of result value. If the
DAG computes multiple values then return type of 'index'th result.
>>
>> 6. !setdagrestype(dag target_dag, type T [, index]) - Set return type
of target_dag to T. Use of 'index' is as in 5.(Coupled with the existing
(or enhanced?) foreach construct we can construct multiple DAGs with different
return types.)
>>
>> .7 !setdagchild(dag target_dag, dag new_dag, index) - Set child
'index' numbered of target_dag to new_dag. I think this is more or less
similar to 3 you suggested but I feel it is more convenient and concise.
>>
>> 8. !setdagchildcond(dag target_dag, dag new_dag, index, {C++ code}) -
Similar to 7 above but do it only if the C++ code returns true. This is useful
to check if the result type of `new_dag` and that of the operand type of
'index' child of 'target_dag' are compatible. Users can define
compatibility using C++ code. For example, it is okay to set dag even if there
is mismatch between signedness of types.
>
>All of these sound like operations that are specific to TableGen
>backend interpretations of what a DAG means. This discussion is about
>!ops which are a part of the TableGen frontend, so I don't think any
>of these apply here.
>
>Cheers,
>Nicolai

On Tue, Oct 13, 2020 at 8:07 PM Paul C. Anagnostopoulos <paul at
windfall.com>
wrote:
> Nicolai:
>
> If we have two operators to get and set DAG operator/operands, does it
> make sense to add to more operators to get/set the $names of operands? They
> would still specify the operand by integer index.
>
> At 10/13/2020 10:16 AM, Nicolai Hähnle wrote:
> >On Tue, Oct 13, 2020 at 10:47 AM Madhur Amilkanthwar
> ><madhur13490 at gmail.com> wrote:
> >> What do you guys think about the below enhancements?
> >>
> >> 5. !getdagrestype(dag [, index]) - Returns type of result value.
If the
> DAG computes multiple values then return type of 'index'th result.
> >>
> >> 6. !setdagrestype(dag target_dag, type T [, index]) - Set return
type
> of target_dag to T. Use of 'index' is as in 5.(Coupled with the
existing
> (or enhanced?) foreach construct we can construct multiple DAGs with
> different return types.)
> >>
> >> .7 !setdagchild(dag target_dag, dag new_dag, index) - Set child
'index'
> numbered of target_dag to new_dag. I think this is more or less similar to
> 3 you suggested but I feel it is more convenient and concise.
> >>
> >> 8. !setdagchildcond(dag target_dag, dag new_dag, index, {C++
code}) -
> Similar to 7 above but do it only if the C++ code returns true. This is
> useful to check if the result type of `new_dag` and that of the operand
> type of 'index' child of 'target_dag' are compatible. Users
can define
> compatibility using C++ code. For example, it is okay to set dag even if
> there is mismatch between signedness of types.
> >
> >All of these sound like operations that are specific to TableGen
> >backend interpretations of what a DAG means. This discussion is about
> >!ops which are a part of the TableGen frontend, so I don't think
any
> >of these apply here.
>
I am not sure why you say so. Isn't 7 and 8 above somewhere similar to
*!con* already offered by the language?  !con allows you to concatenate two
DAGs, 5 allows you to connect two DAGs to form a bigger DAG. You may be
able to achieve the same today with existing the language constructs but I
don't see a concise way to do this.

5 and 6 are subject to debate but since it's a language an addition like
this could be useful.

>Cheers,
> >Nicolai
>
>
-- 
*Disclaimer: Views, concerns, thoughts, questions, ideas expressed in this
mail are of my own and my employer has no take in it. *
Thank You.
Madhur D. Amilkanthwar
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201013/475b8002/attachment.html>

Madhur, could you describe !getdagrestype in more detail? In particular, I
don't know what "type of result value" means.

On Tue, Oct 13, 2020, 10:44 PM Paul C. Anagnostopoulos <paul at
windfall.com>
wrote:
> Madhur, could you describe !getdagrestype in more detail? In particular, I
> don't know what "type of result value" means.
>
I mean the data type of the result computed by a DAG node. A DAG node may
receive a bunch of values from others nodes, applies its operator and
returns an 'int', so its restype is 'int', for example.

Does that make sense?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201014/c693c4aa/attachment.html>

On Tue, Oct 13, 2020 at 4:37 PM Paul C. Anagnostopoulos
<paul at windfall.com> wrote:
> Nicolai:
>
> If we have two operators to get and set DAG operator/operands, does it make
sense to add to more operators to get/set the $names of operands? They would
still specify the operand by integer index.
Yes, I do think that would be helpful. For setting, I think you'd want
to set the child and name at the same time, i.e. something like
!setdag(dag_to_modify, index1, value1, name1, index2, value2, name2,
...). Either valueN or nameN can be `?` (unset).

Cheers,
Nicolai

>
> At 10/13/2020 10:16 AM, Nicolai Hähnle wrote:
> >On Tue, Oct 13, 2020 at 10:47 AM Madhur Amilkanthwar
> ><madhur13490 at gmail.com> wrote:
> >> What do you guys think about the below enhancements?
> >>
> >> 5. !getdagrestype(dag [, index]) - Returns type of result value.
If the DAG computes multiple values then return type of 'index'th
result.
> >>
> >> 6. !setdagrestype(dag target_dag, type T [, index]) - Set return
type of target_dag to T. Use of 'index' is as in 5.(Coupled with the
existing (or enhanced?) foreach construct we can construct multiple DAGs with
different return types.)
> >>
> >> .7 !setdagchild(dag target_dag, dag new_dag, index) - Set child
'index' numbered of target_dag to new_dag. I think this is more or less
similar to 3 you suggested but I feel it is more convenient and concise.
> >>
> >> 8. !setdagchildcond(dag target_dag, dag new_dag, index, {C++
code}) - Similar to 7 above but do it only if the C++ code returns true. This is
useful to check if the result type of `new_dag` and that of the operand type of
'index' child of 'target_dag' are compatible. Users can define
compatibility using C++ code. For example, it is okay to set dag even if there
is mismatch between signedness of types.
> >
> >All of these sound like operations that are specific to TableGen
> >backend interpretations of what a DAG means. This discussion is about
> >!ops which are a part of the TableGen frontend, so I don't think
any
> >of these apply here.
> >
> >Cheers,
> >Nicolai
>

-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.