https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102650
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
Target Milestone|--- |12.0
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed| |2021-10-11
Summary|Dead Code Elimination |[12 Regression] Dead Code
|Regression at -O3 (trunk vs |Elimination Regression at
|11.2.0) |-O3 (trunk vs 11.2.0)
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #1)
> This is a result of the vagaries of the single subrange value-range.
>
> VRP is seeing:
> # f_11 = PHI <-1(2), 2(3)>
> goto <bb 6>; [100.00%]
>
> <bb 5> [local count: 955630225]:
> _3 = (unsigned short) f_11;
> _6 = _3 + 2;
> e_19 = (short int) _6;
>
> It knows f_11 is [-1, 2] and when that is cast to a ushort, produces ~[3,
> 65534].
>
> That is all we knew about it in GCC11, so when we calculate_6 = ~[3,65534] +
> 2 it comes up with [1,4] and the e_19 == 0 later on then can be folded away.
>
> in gcc12, EVRP has figured out that _3 is unsigned short [2, 2][+INF, +INF].
> which if we add 2 to it, would come up with [1,1][4,4] which would be
> perfect.
>
> We save this to the value_range global table in EVRP, but alas it gets
> transliterated to a single pair value_range : _3 : unsigned short [2, +INF]
That translation could see whether the corresponding anti-rante ~[3,65534] is
smaller (which it is) and use that instead?
