Re: [PATCH v2] RISC-V: Produce better code with complex constants [PR95632] [PR106602]

[Jeff Law <jeffreyalaw@gmail.com>]

On 12/9/22 11:25, Raphael Moreira Zinsly wrote:
> Changes since v1:
> 	- Fixed formatting issues.
> 	- Added a name to the define_insn_and_split pattern.
> 	- Set the target on the 'dg-do compile' in pr106602.c.
> 	- Removed the rv32 restriction in pr95632.c.
> 
> -- >8 --
> 
> Due to RISC-V limitations on operations with big constants combine
> is failing to match such operations and is not being able to
> produce optimal code as it keeps splitting them.  By pretending we
> can do those operations we can get more opportunities for
> simplification of surrounding instructions.
> 
> 2022-12-06  Raphael Moreira Zinsly  <rzinsly@ventanamicro.com>
> 	    Jeff Law  <jlaw@ventanamicro.com>
> 
> gcc/Changelog:
> 	PR target/95632
> 	PR target/106602
> 	* config/riscv/riscv.md: New pattern to simulate complex
> 	const_int loads.
> 
> gcc/testsuite/ChangeLog:
> 	* gcc.target/riscv/pr95632.c: New test.
> 	* gcc.target/riscv/pr106602.c: New test.
So I was doing a bit of testing around this.  I think we need we're 
going to need a v3.

The problem is at -O1 several passes do not run.  In particular the 
post-loop CSE pass isn't run.  That causes cse_not_expected to be set 
earlier in the pipeline which in turn means the new pattern is exposed 
to fwprop -- too early IMHO and with more potential to cause minor 
regressions as can be seen with riscv/load-immediate.c

Given that bridge patterns are fairly standard and that combining, then 
resplitting has also become relatively standard (particularly for 
eliminating some data dependencies and late lowering) having a state 
variable to indicate that combine has started and such patterns should 
be exposed seems sensible.

An alternate approach would be to do something more hackish like adding 
&& flag_rerun_cse_after_loop to the condition.  That's better than what 
we do now, but not as accurate as biting the bullet and making a state 
variable for combine.

I'll cobble something together and test it.  It'll require a wider test 
because it'll touch target independent files.

Jeff