Hi!
On Wed, Mar 17, 2021 at 03:49:09PM -0500, Pat Haugen wrote:
> This patch creates a new attribute, prepend_prefixed_insn, which is used to
> mark
> those instructions that are prefixed and need to have a 'p' prepended to their
> mnemonic at asm emit time. The existing "prefix" attribute is now used to mark
> all instructions that are prefixed form.
But it doesn't. The "prepend_prefixed_insn" attribute forces the
"prefixed" attribute to be on, whether the insn is prefixed or not.
Please change it so that "prefixed" just means whether the instruction
is prefixed, and a new attribute "maybe_prefixed" that marks the insns
that potentially are prefixed. Similar to how "var_shift" and
"maybe_var_shift" work. The default value of "prefixed" can set the
attribute to either "yes" if "maybe_prefixed" is set, and the insn
should get a "p" mnemonic.
Btw, attributes describe some property of insns. They do not say what
any particular part of the compiler should do with the insns.
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -26283,7 +26283,8 @@ static bool prepend_p_to_next_insn;
> void
> rs6000_final_prescan_insn (rtx_insn *insn, rtx [], int)
> {
> - prepend_p_to_next_insn = (get_attr_prefixed (insn) != PREFIXED_NO);
> + prepend_p_to_next_insn = (get_attr_prepend_prefixed_insn (insn)
> + == PREPEND_PREFIXED_INSN_YES);
> return;
> }
But the new attribute here is set if the insn *can* be prefixed, not if
it *is*.
> --- a/gcc/config/rs6000/sync.md
> +++ b/gcc/config/rs6000/sync.md
> @@ -132,9 +132,10 @@ (define_insn "load_quadpti"
> "lq %0,%1"
> [(set_attr "type" "load")
> (set_attr "size" "128")
> - (set (attr "prefixed") (if_then_else (match_test "TARGET_PREFIXED")
> - (const_string "yes")
> - (const_string "no")))])
> + (set (attr "prepend_prefixed_insn")
> + (if_then_else (match_test "TARGET_PREFIXED")
> + (const_string "yes")
> + (const_string "no")))])
(bad whitespace)
I don't think this is correct. We need to force the use of "plq" here
(for LE only actually, that should be fixed some day). Maybe we should
have a separate instruction pattern for it, even, since its semantics
differ very significantly :-)
Segher
