* Basic REG_EQUIV comprehension question
@ 2022-09-15 11:38 Robin Dapp
2022-09-15 11:45 ` Robin Dapp
2022-09-15 11:53 ` Richard Sandiford
0 siblings, 2 replies; 4+ messages in thread
From: Robin Dapp @ 2022-09-15 11:38 UTC (permalink / raw)
To: GCC Patches
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Basic REG_EQUIV comprehension question
2022-09-15 11:38 Basic REG_EQUIV comprehension question Robin Dapp
@ 2022-09-15 11:45 ` Robin Dapp
2022-09-15 11:53 ` Richard Sandiford
1 sibling, 0 replies; 4+ messages in thread
From: Robin Dapp @ 2022-09-15 11:45 UTC (permalink / raw)
To: gcc-patches
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Basic REG_EQUIV comprehension question
2022-09-15 11:38 Basic REG_EQUIV comprehension question Robin Dapp
2022-09-15 11:45 ` Robin Dapp
@ 2022-09-15 11:53 ` Richard Sandiford
2022-09-15 12:03 ` Robin Dapp
1 sibling, 1 reply; 4+ messages in thread
From: Richard Sandiford @ 2022-09-15 11:53 UTC (permalink / raw)
To: Robin Dapp via Gcc-patches; +Cc: Robin Dapp
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Basic REG_EQUIV comprehension question
2022-09-15 11:53 ` Richard Sandiford
@ 2022-09-15 12:03 ` Robin Dapp
0 siblings, 0 replies; 4+ messages in thread
From: Robin Dapp @ 2022-09-15 12:03 UTC (permalink / raw)
To: Robin Dapp via Gcc-patches, richard.sandiford
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-09-15 12:03 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-15 11:38 Basic REG_EQUIV comprehension question Robin Dapp
2022-09-15 11:45 ` Robin Dapp
2022-09-15 11:53 ` Richard Sandiford
2022-09-15 12:03 ` Robin Dapp
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).