llvm dev - Oct 2020 - Manipulating DAGs in TableGen

This is a proposal to enhance TableGen's ability to analyze and manipulate
DAGs. Hopefully this will allows more complex DAGs to be built in TableGen.

1. Add a new value suffix.

   value(index)

   The value must be a DAG. The index specifies the operator or an operand,
   whose value is produced. The index can be

   0            produce the operator
   1...n        produce operand by position
   $name        produce operator/operand by its variable name
   string       produce operator/operand by a string containing its
                variable name

   If the item does not exist, ? (uninitialized) is produced.

   Note that multiple value suffixes are allowed, so, for example,
   DagList[i](1) would produce the first operand of the i-th dag
   in the list.

2. Add the !getdag() bang operator.

   !getdag(dag, index [, default])

   This bang operator produces the same result as the (...) suffix.
   However, the default value can be specified as the third argument.
   If it is not specified, ? is used.

3. Add the !setdag bang operator.

   !setdag(dag, index1, value1, index2, value2, ...)

   This bang operator creates a copy of the top-level dag node and
   then replaces the operator and/or operands with new values. Each
   replacement is specified by an index and a value. The new dag
   is produced.

The two new bang operators replace !getop() and !setop(), which could be
deprecated.

4. The !size operator will be extended to accept a DAG and produce
   the number of operands in it.

Hi Paul,

On Sun, Oct 11, 2020 at 4:55 PM Paul C. Anagnostopoulos via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> This is a proposal to enhance TableGen's ability to analyze and
manipulate
> DAGs. Hopefully this will allows more complex DAGs to be built in TableGen.
>
> 1. Add a new value suffix.
>
>    value(index)
>
>    The value must be a DAG. The index specifies the operator or an operand,
>    whose value is produced. The index can be
>
>    0            produce the operator
>    1...n        produce operand by position
This seems reasonable.

>    $name        produce operator/operand by its variable name
>    string       produce operator/operand by a string containing its
>                 variable name
I don't like this part, because to me is seems to conflate what the
indices vs. name operands in DAGs are for. We can often think of DAG
operators as functions, and the operands are arguments of the
function. So using a numeric index would return an argument of a given
index. However, the $names are _not_ names of function arguments! They
are a mechanism for tagging DAG nodes that are interesting as part of
pattern matching.

So please don't add this functionality, and definitely don't add it in
this way. If there is a convincing reason for extracting DAG nodes by
name, then it should be done via a different ! accessor that performs
a deep search of the DAG (i.e., it can produce DAG nodes inside
arbitrarily deeply nested children).

>    If the item does not exist, ? (uninitialized) is produced.
I think it would be better for this to fail instead (i.e., not fold
and produce an error at final resolution). Especially since you
propose !getdag below.

>    Note that multiple value suffixes are allowed, so, for example,
>    DagList[i](1) would produce the first operand of the i-th dag
>    in the list.
>
> 2. Add the !getdag() bang operator.
>
>    !getdag(dag, index [, default])
>
>    This bang operator produces the same result as the (...) suffix.
>    However, the default value can be specified as the third argument.
>    If it is not specified, ? is used.
As above, I would suggest having to specify ? explicitly.

> 3. Add the !setdag bang operator.
>
>    !setdag(dag, index1, value1, index2, value2, ...)
>
>    This bang operator creates a copy of the top-level dag node and
>    then replaces the operator and/or operands with new values. Each
>    replacement is specified by an index and a value. The new dag
>    is produced.
>
> The two new bang operators replace !getop() and !setop(), which could be
> deprecated.
>
> 4. The !size operator will be extended to accept a DAG and produce
>    the number of operands in it.
Sounds good.

Cheers,
Nicolai


>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


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

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?

Perhaps the people actually coding these DAGs have it all down in their minds by
position anyway.

At 10/12/2020 12:40 PM, Nicolai Hähnle wrote:
>Hi Paul,
>
>On Sun, Oct 11, 2020 at 4:55 PM Paul C. Anagnostopoulos via llvm-dev
><llvm-dev at lists.llvm.org> wrote:
>> This is a proposal to enhance TableGen's ability to analyze and
manipulate
>> DAGs. Hopefully this will allows more complex DAGs to be built in
TableGen.
>>
>> 1. Add a new value suffix.
>>
>>    value(index)
>>
>>    The value must be a DAG. The index specifies the operator or an
operand,
>>    whose value is produced. The index can be
>>
>>    0            produce the operator
>>    1...n        produce operand by position
>
>This seems reasonable.
>
>
>>    $name        produce operator/operand by its variable name
>>    string       produce operator/operand by a string containing its
>>                 variable name
>
>I don't like this part, because to me is seems to conflate what the
>indices vs. name operands in DAGs are for. We can often think of DAG
>operators as functions, and the operands are arguments of the
>function. So using a numeric index would return an argument of a given
>index. However, the $names are _not_ names of function arguments! They
>are a mechanism for tagging DAG nodes that are interesting as part of
>pattern matching.
>
>So please don't add this functionality, and definitely don't add it
in
>this way. If there is a convincing reason for extracting DAG nodes by
>name, then it should be done via a different ! accessor that performs
>a deep search of the DAG (i.e., it can produce DAG nodes inside
>arbitrarily deeply nested children).
------------------------------------

Agreed.
>>    If the item does not exist, ? (uninitialized) is produced.
>
>I think it would be better for this to fail instead (i.e., not fold
>and produce an error at final resolution). Especially since you
>propose !getdag below.
----------------------------------------

Agreed.
>> 2. Add the !getdag() bang operator.
>>
>>    !getdag(dag, index [, default])
>>
>>    This bang operator produces the same result as the (...) suffix.
>>    However, the default value can be specified as the third argument.
>>    If it is not specified, ? is used.
>
>As above, I would suggest having to specify ? explicitly.