llvm dev - Oct 2020 - Manipulating DAGs in TableGen

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

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.



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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201013/099b3e0b/attachment.html>

I'm not sure what you mean by "type of result value." Can you
explain further?

At 10/13/2020 04:46 AM, Madhur Amilkanthwar 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.

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.