[llvm-dev] Manipulating DAGs in TableGen

[Nicolai Hähnle via llvm-dev]

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.