On Fri, Jun 21, 2024 at 09:50:43PM +0200, Georg-Johann Lay wrote:
>
>
> Am 17.06.24 um 21:13 schrieb Stefan Schulze Frielinghaus via Gcc:
> > Hi all,
> >
> > I'm trying to add an alternative to an existing insn foobar:
> >
> > (define_insn "foobar"
> > [(set (match_operand ...)
> > (match_operand ...))]
> > ""
> > "@
> > foo
> > bar
> > #")
> >
> > Since the asm output depends on the operands in a non-trivial way which
> > isn't
> > easily solved via iterators, I went for a general C function and came up
> > with:
> >
> > (define_insn "foobar"
> > [(set (match_operand ...)
> > (match_operand ...))]
> > ""
> > "@
> > foo
> > * return foobar_helper (operands[0], operands[1]);
> > bar
> > #"
> > [(set_attr_alternative "mnemonic" [(const_string "foo")
> > (const_string "specialcase")
> > (const_string "bar")
> > (const_string "unknown")])])
> >
> > If there exist a lot of alternatives, then setting the mnemonic attribute
> > like
> > this feels repetitive and is error prone. Furthermore, if there exists no
> > other insn with an output template containing foo/bar, then I would have to
> > declare foo/bar via
> >
> > (define_attr "mnemonic" "...,foo,bar,..." (const_string "unknown"))
> >
> > which again is repetitive. Thus, I'm wondering if there exists a more
> > elegant
> > way to achieve this? Ultimately, I would like to set the mnemonic
> > attribute only manually for the alternative which is implemented via C
> > code and let the mnemonic attribute for the remaining alternatives be
> > set automagically. Not sure whether this is supported?
> >
> > If all fails, I have another idea how to solve this by utilizing
> > PRINT_OPERAND.
> > However, now I'm curious whether my current attempt is feasible or not.
> >
> > Cheers,
> > Stefan
>
> It's a bit unclear to me what you are trying to do, as you are not only
> adding an insn alternative, but also are adding insn attribute
> "mnemonic", which the original insn did not have.
My take so far is that every insn has a mnemonic attribute which is set
either explicitly or implicitly (assuming that the target requested this
via define_attr "mnemonic" "..."). This is done in function
gen_mnemonic_attr() from gensupport.cc. Thus, something like
(define_insn "foobar"
[(set (match_operand ...)
(match_operand ...))]
""
"@
foo
bar
#")
and
(define_insn "foobar"
[(set (match_operand ...)
(match_operand ...))]
""
"@
foo
bar
#"
[(set_attr_alternative "mnemonic" [(const_string "foo")
(const_string "bar")
(const_string "unknown")])])
should be equivalent.
Of course, the implicit method fails if the pattern is generated via C
statements which is way I set it manually in the initial example. The
initial example contained 3 alternatives plus 1 for the generated one.
Setting it manually there might be feasible, however, for my actual
problem I have an insn with 27 alternatives where I do not want to set
and maintain it manually. A side effect of setting the attribute
implicitly is that each mnemonic is added automatically to the mnemonic
hash table which I would have to do manually for my 27 alternatives
which I would like to avoid, too.
>
> Also, it's unclear how PRINT_OPERAND would help with setting the attribute.
For my particular problem I think one can also utilize PRINT_OPERAND
which I should have elaborated a bit more but feared to make the example
unnecessarily complicated. The C code
foobar_helper (operands[0], operands[1])
emits actually an extended mnemonic "specialcase$VAR\t%0,%1" where $VAR
can be either A, B, or C. The extended mnemonic is just syntactic sugar
for the base mnemonic "specialcase\t%0,%1,$IMM" which is why we can lie
and hard code the mnemonic attribute to specialcase since this won't
effect scheduling. Since the choice which extended mnemonic should be
used depends only on operands[1] I thought about rewriting all this into
(define_insn "foobar"
[(set (match_operand ...)
(match_operand ...))]
""
"@
foo
specialcase\t%0,%1,%X1
bar
#")
Obviously we have to sacrifice the usage of an extended mnemonic but
more problematic is that we have to allocate one of those very few codes
X just for this insn. So this doesn't scale either if one has to come
up with many different codes. Furthermore, this only works in my very
particular case since I can split the extended mnemonic into a base
mnemonic and an immediate which only depends on one operand, i.e., it
would fail if it depended on operands[0] and operands[1].
I hope this makes it a bit more clear, if not just let me know.
Cheers,
Stefan
>
> Johann
