[Rewriter] custom name rule for hidden tensors

[Johansmm]

I would like to know if it is possible to customize the hidden tensors for nodes created by a rewriter replacement function through a rule format (e.g. regex, prefix, ...). Today I see all are created as val_x.

[justinchuby]

I think that would be helpful! Do you have any suggestions on the apis?

[Johansmm]

I think that would be helpful! Do you have any suggestions on the apis?

What about on three levels:

1. Specific node name over each node in replacement functions ([Rewriter] Cannot create an op with a name #2435):

def replacement_fn(op, x)
    return op.NewOp(x, name=new_node_name, output_name=new_name)

2. In pattern.RewriteRule:

pattern.RewriteRule(target_pattern, replacement_pattern, regex_name=r'prefix_{idx}_postfix')

3. In pattern.RewriteRuleSet

pattern.RewriteRuleSet([rule_1, rule_2, ...], regex_name=r'prefix_{idx}_postfix')

Note I wrote the levels by priority.

Also, it would be nice to have identifiers: regex_name=r'{OP_TYPE}_{idx}' (to be defined).

What do you think?

[justinchuby]

For 1 I wonder how we can avoid naming conflicts? It's aways something annoying to deal with. Should the rewriter handle it if there are any duplicates, so "output_name" and "node_name" become "best effort"?

[Johansmm]

Is it too expensive to throw an exception when a collision is encountered (comparing with all available names)? Like @AyoubMDL, I think it would be an error of the user and not of the algorithm.

[justinchuby]

Without a mechanism to generate a unique name, I fear this would make rewrite rules less robust than they can be. How can we ensure this is always robust and meet user expectations?

[Johansmm]

@justinchuby I do not sure to know which are the user expectations? But in any way, if node name is an issue, we can start with tensor's name

[gramalingam]

For value names: I see that this line ignores the contents of the list. Why not treat the contents as names of output values? (Just addressing level 1 option in @Johansmm's list.)

As for name-conflicts: that is an issue even when users explicitly construct the same IR via the IR API, right? The API will let me create values with specific names, and pass them as "outputs" in the node-constructor ... so, following the same in the rewriter context doesn't introduce any new issue. It can be handled the same way conflicts are currently handled in the underlying IR.