On 8/24/23 08:06, Robin Dapp via Gcc-patches wrote:
Ping. I refined the code and some comments a bit and added a test
case.
My question in general would still be: Is this something we want
given that we potentially move some of combine's work a bit towards
the front of the RTL pipeline?
Regards
Robin
Subject: [PATCH] fwprop: Allow UNARY_P and check register pressure.
This patch enables the forwarding of UNARY_P sources. As this
involves potentially replacing a vector register with a scalar register
the ira_hoist_pressure machinery is used to calculate the change in
register pressure. If the propagation would increase the pressure
beyond the number of hard regs, we don't perform it.
gcc/ChangeLog:
* fwprop.cc (fwprop_propagation::profitable_p): Add unary
handling.
(fwprop_propagation::update_register_pressure): New function.
(fwprop_propagation::register_pressure_high_p): New function
(reg_single_def_for_src_p): Look through unary expressions.
(try_fwprop_subst_pattern): Check register pressure.
(forward_propagate_into): Call new function.
(fwprop_init): Init register pressure.
(fwprop_done): Clean up register pressure.
(fwprop_insn): Add comment.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/binop/vadd-vx-fwprop.c: New test.
So I was hoping that Richard S. would chime in here as he knows this
code better than anyone.
This looks like a much better implementation of something I've done
before :-) Basically imagine a target where a sign/zero extension can
be folded into arithmetic for free. We put in various hacks to this
code to encourage more propagations of extensions.
I still think this is valuable. As we lower from gimple->RTL we're
going to still have artifacts in the RTL that we're going to want to
optimize away. fwprop has certain advantages over combine, including
the fact that it runs earlier, pre-loop.
It looks generally sensible to me. But give Richard S. another week to
chime in. He seems to be around, but may be slammed with stuff right now.
jeff
