https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #15 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #14)
> I think the easiest fix is move optimize_bit_field_compare from where it is
> currently done and do it only in some late gimple pass, around
> pass_fold_builtins/store merging or so? Dunno which exact one though.
Delaying optimize_bit_field_compare, would definitely do the trick. For that
matter, disabling it, at least in this particular case, causes FRE to sensibly
realize the nonsense in:
<bb 2> :
_1 = tp_10(D)->chrono_type;
_2 = (int) _1;
if (_1 == 0)
goto <bb 3>; [INV]
else
goto <bb 5>; [INV]
<bb 3> :
_3 = tp_10(D)->chrono_type;
if (_3 != 0)
goto <bb 4>; [INV]
else
goto <bb 5>; [INV]
...and clean things up. By VRP we no longer have a problematic store, and the
warning is gone.
However, wouldn't optimizing bit field compares so late inhibit other
optimizations that come before store merging??? Though come to think of it,
optimizing bit fields so early (in the FE currently) seems mighty early.
I don't know whether Richard was frowning upon optimize_bit_field_compare
twiddling in comment 7.
Also, doing it in gimple, instead of the FE, means we have to recreate the bit
field comparison that's been gimplified. We no longer have a comparison but:
_3 = tp_10(D)->chrono_type;
if (_3 != 0)
or worse:
_1 = tp_10(D)->chrono_type;
_2 = (int) _1;
if (_1 == 0)
I'm certainly willing to tackle this, but I want to make sure I don't throw
cycles away.
Thoughts?
Richard, Jeff, Jakub?
