[Bug target/105136] [11/12 regression] Missed optimization regression with 32-bit adds and shifts

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105136

--- Comment #4 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
I am just saying trivial things here that RA is a NP-complete task and there is
no optimal solution for all tests.  For GCC it is even more complicated as RA
solves code selection tasks too.  Basically we have for this test

p91=di
p92=si
...
p89=p92+p87 (dead p92)
p97=p91>>const (dead p91)
p83=flags?p87:p89 (dead p87, p89)
ax=p83

RA creates the following relations (to propagate assignment costs) for pseudos

p83(ax preferred)---p87---p91(di preferred)
\
 \------------------p89---p92(si preferred)

Only assignment ax for p89 can create the desired code.  Relation costs of
p87--p91 and p89--p92 or p83--p87 and p83--p89 are the same even if we use
--param ira-consider-dup-in-all-alts=1.

To get the right guaranteed solution we need some greedy algorithm which will
take a lot of time to work and check results not only at the end of IRA but at
the end LRA.

I can revert meaningful changes of the patch which resulted in this
degradation.  But as I can see this creates 3 new test failures for tests
avx512fp16-conjugation-1.c and avx512fp16vl-conjugation-1.c.  Also I can not
guarantee that such change will not result in more serious benchmark (e.g.
SPEC) degradation.

But in any I can try to do this.  Although I am not sure taht it is worth to do
this at this stage of gcc-12 release work.

Richard and Jakub, what your thoughts about reverting my patch in question?