https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127364
Drea Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2026-09-14
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #3 from Drea Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> RTL never associates floating point (well, that was the case in the past
> when I added PAREN_EXPR ...)
Combine:
Trying 8, 12, 9 -> 13:
8: r107:V4SF=const_vector
REG_EQUAL const_vector
12: r110:V4SF=const_vector
REG_EQUAL const_vector
9: r106:V4SF=r113:V4SF+r107:V4SF
REG_DEAD r113:V4SF
REG_DEAD r107:V4SF
13: r105:V4SF=r106:V4SF+r110:V4SF
REG_DEAD r110:V4SF
REG_DEAD r106:V4SF
Successfully matched this instruction:
(set (reg:V4SF 105 [ _5 ])
(reg:V4SF 113 [ xD.26115 ]))
I had thought a 4 insn combine was newish; being 16 years old is NOT new after
all; r0-102326-g0524d2d6623eb2
>RTL never associates floating point
This is not true, it does simple re-association (and simplifications) and has
since at least r0-52270-gdd61aa98caa43a while PAREN_EXPR was added with
r0-85884-gdedd42d511b6e4.
Why the scalar version does not do the same I have not looked into that.