<div dir="ltr"><div>What do you guys think about the below enhancements?</div><div><br></div><div>5. !getdagrestype(dag [, index]) - Returns type of result value. If the DAG computes multiple values then return type of 'index'th result.<br></div><div><br></div><div>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.)<br></div><div><br></div><div>.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.</div><div><br></div><div>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.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 12, 2020 at 11:31 PM Paul C. Anagnostopoulos via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<br>
So DAG indexes are integers only.<br>
<br>
<br>
At 10/12/2020 01:46 PM, Nicolai Hähnle wrote:<br>
>On Mon, Oct 12, 2020 at 7:37 PM Paul C. Anagnostopoulos<br>
><<a href="mailto:paul@windfall.com" target="_blank">paul@windfall.com</a>> wrote:<br>
>> 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?<br>
><br>
>My point is precisely that the $names don't work that way. Your<br>
>reasoning would be valid if the $names were function/operator argument<br>
>names, like in programming languages where you can pass function<br>
>arguments based on their order but also by naming them (e.g.<br>
>"functionName(argName=x, otherArgName=y)"). However, this is _not_ how<br>
>$names work!<br>
><br>
>Their most prominent application is for instruction selection pattern<br>
>matching, e.g. taken at random from AMDGPU/SOPInstructions.td:<br>
><br>
>def : GCNPat <<br>
> (i32 (smax i32:$x, (i32 (ineg i32:$x)))),<br>
> (S_ABS_I32 SReg_32:$x)<br>
>>;<br>
><br>
>The $x is _not_ the name of the argument to smax, ineg, or S_ABS_I32.<br>
>For example, if you look at how S_ABS_I32 is defined, you'll see that<br>
>its input operand is called $src0.<br>
><br>
>Instead, the name allows us to tie three locations in the DAG together<br>
>for purposes of pattern matching. The name is only meaningful in the<br>
>context of this pattern. You could substitute $x by $y or $whatever<br>
>without changing the meaning of the DAG.<br>
><br>
>That the name is the name of an operator argument is an understandable<br>
>misunderstanding, but it _is_ a misunderstanding. If you were to add<br>
>that particular feature, you would encourage this misunderstanding<br>
>even more.<br>
<br>
<br>
----------------------------------------------------------------<br>
Windfall Paul C. Anagnostopoulos <br>
----------------------------------------------------------<br>
Software 978 369-0839<br>
<a href="http://www.windfall.com" rel="noreferrer" target="_blank">www.windfall.com</a><br>
----------------------------------------------------------------<br>
My life has been filled with calamities,<br>
some of which actually happened.<br>
---Mark Twain <br>
<br>
Guga 'mzimba, sala 'nhliziyo <br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><i style="font-size:12.8px">Disclaimer: Views, concerns, thoughts, questions, ideas expressed in this mail are of my own and my employer has no take in it. </i><br></div><div>Thank You.<br>Madhur D. Amilkanthwar<br><br></div></div></div>