Basic REG_EQUIV comprehension question

Basic REG_EQUIV comprehension question

[Robin Dapp]

Hi,

I have been working on making better use of s390's vzero instruction.
Currently we rather zero a vector register once and load it into other
registers via vlr instead of emitting multiple vzeros.

At IRA/reload point we e.g. have

(insn 8 5 19 2 (set (reg/v:V2DI 64 [ zero ])
        (const_vector:V2DI [
                (const_int 0 [0]) repeated x2
            ])) "vzero-vs-vlr.c":18:17 412 {movv2di}
     (expr_list:REG_EQUIV (const_vector:V2DI [
                (const_int 0 [0]) repeated x2 ])
        (nil)))

so reg 64 is equivalent to a const_vector 0.  I expected ira/reload to
match our move pattern (abbreviated for readability)

(define_insn "mov<mode>"
  [(set (match_operand:V_64 0 "nonimmediate_operand" "v")
        (match_operand:V_64 1 "general_operand"      "j00"))]
  "TARGET_ZARCH"
  "@
   vzero\t%v0 [..]

where the j00 constraint is simply

(define_constraint "j00"
  "Zero scalar or vector constant"
  (match_test "op == CONST0_RTX (GET_MODE (op))"))

Apparently this is not what's happening.  The vzero alternative is
rejected since the register is not actually a constant but only
equivalent to one.

It is possible to work around that by changing pattern decisions earlier
but I'd still like to understand what is supposed to happen here.
Should another pass perform the equiv replacement or is this not how all
of this works entirely?  I was also thinking into the direction of
register_move_costs and rtx_costs but at least initial attempts did not
help.

Thanks for clarifying
 Robin

Re: Basic REG_EQUIV comprehension question

[Robin Dapp]

Small addition to clarify:  (insn 8) from the example is of course
matched to a vzero.  The "problem" begins when (reg 64) is later moved
into another register and the (const_vector) has been optimized to a
single definition e.g. by CSE, i.e. we have several

(insn yy (set (reg:V2DI xx) (reg:V2DI 64 [zero])) where (reg 64) is
equivalent to a (const_vector 0).

Regards
 Robin

Re: Basic REG_EQUIV comprehension question

[Richard Sandiford]

Robin Dapp via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> Hi,
>
> I have been working on making better use of s390's vzero instruction.
> Currently we rather zero a vector register once and load it into other
> registers via vlr instead of emitting multiple vzeros.
>
> At IRA/reload point we e.g. have
>
> (insn 8 5 19 2 (set (reg/v:V2DI 64 [ zero ])
>         (const_vector:V2DI [
>                 (const_int 0 [0]) repeated x2
>             ])) "vzero-vs-vlr.c":18:17 412 {movv2di}
>      (expr_list:REG_EQUIV (const_vector:V2DI [
>                 (const_int 0 [0]) repeated x2 ])
>         (nil)))
>
> so reg 64 is equivalent to a const_vector 0.  I expected ira/reload to
> match our move pattern (abbreviated for readability)
>
> (define_insn "mov<mode>"
>   [(set (match_operand:V_64 0 "nonimmediate_operand" "v")
>         (match_operand:V_64 1 "general_operand"      "j00"))]
>   "TARGET_ZARCH"
>   "@
>    vzero\t%v0 [..]
>
> where the j00 constraint is simply
>
> (define_constraint "j00"
>   "Zero scalar or vector constant"
>   (match_test "op == CONST0_RTX (GET_MODE (op))"))
>
> Apparently this is not what's happening.  The vzero alternative is
> rejected since the register is not actually a constant but only
> equivalent to one.
>
> It is possible to work around that by changing pattern decisions earlier
> but I'd still like to understand what is supposed to happen here.
> Should another pass perform the equiv replacement or is this not how all
> of this works entirely?  I was also thinking into the direction of
> register_move_costs and rtx_costs but at least initial attempts did not
> help.

Yeah, rtx_costs (or preferably insn_cost, if that works) seem like the
best way of addressing this.  If the target says that register moves are
cheaper than constant moves then it's a feature that CSE & co remove
duplicate constants.  The REG_EQUIV note is still useful in those cases
because the note tells IRA/LRA that if the source operand is spilled,
it would be possible to rematerialise the source value (rather than spill
the original source operand and reload it from the stack).

Thanks,
Richard

Re: Basic REG_EQUIV comprehension question

[Robin Dapp]

> Yeah, rtx_costs (or preferably insn_cost, if that works) seem like the
> best way of addressing this.  If the target says that register moves are
> cheaper than constant moves then it's a feature that CSE & co remove
> duplicate constants.  The REG_EQUIV note is still useful in those cases
> because the note tells IRA/LRA that if the source operand is spilled,
> it would be possible to rematerialise the source value (rather than spill
> the original source operand and reload it from the stack).

Thanks, that's reasonable.  So the mechanism I thought of (match
alternatives via REG_EQUIV) doesn't exist and we should generally make
sure not to end up in such situations.

Thanks
 Robin