[llvm-dev] Manipulating DAGs in TableGen

[Madhur Amilkanthwar via llvm-dev]

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>