https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113838
Xi Ruoyao <xry111 at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |xry111 at gcc dot gnu.org
--- Comment #6 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to absoler from comment #3)
> The gimple ir has no problem, but `_13` is replaced with g_26[5][3][0] in
> the follow-up process, this shouldn't be expected behavior.
>
> We question this option because we found in an older version of gcc
> (10.2.0), only the O2 option is needed to produce the same bad code, so we
> worry about there's a hidden un-fixed problem and it's re-triggered by this
> option.
>
> Besides, the bad binary code introduce more load operation than the source
> code (without optimization), so we thought it's necessary to check it
> regardless of which optimization is disabled.
(In reply to absoler from comment #5)
> (In reply to Andrew Pinski from comment #2)
> > The difference from the gimple level IR:
> > ```
> > _14 = g_26[5][3][0];
> > _15 = (int) _14;
> > _16 = _13 ^ _15;
> > g_51 = _16;
> > if (_13 != _15)
> > ```
> >
> > vs:
> > ```
> > _14 = g_26[5][3][0];
> > _15 = (int) _14;
> > _16 = _13 ^ _15;
> > g_51 = _16;
> > if (_16 != 0)
> > goto <bb 4>; [50.00%]
> > else
> > goto <bb 3>; [50.00%]
> > ```
> >
> >
> > This is expected behavior even for the x86_64 target
>
> The gimple ir has no problem, but `_13` is replaced with g_26[5][3][0] in
> the follow-up process, this shouldn't be expected behavior.
No. GIMPLE pass knows nothing about register pressure, _13 is only a temporary
variable, not necessarily an register.
> We question this option because we found in an older version of gcc
> (10.2.0), only the O2 option is needed to produce the same bad code, so we
> worry about there's a hidden un-fixed problem and it's re-triggered by this
> option.
So are you expecting a bug must be fixed in at least two different passes and
any -fno-* option shouldn't regress the code? No this won't happen.
