[Bug middle-end/115863] [15 Regression] zlib-1.3.1 miscompilation since r15-1936-g80e446e829d818

[pan2.li at intel dot com]

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

--- Comment #8 from Li Pan <pan2.li at intel dot com> ---
(In reply to Richard Biener from comment #7)
> (In reply to Uroš Bizjak from comment #6)
> > Please note that w/o .SAT_TRUNC the compiler is able to optimize hot loop in
> > compress2 to:
> > 
> >   <bb 5> [local count: 536870912]:
> >   _18 = MIN_EXPR <left_8, 4294967295>;
> >   iftmp.0_11 = (unsigned int) _18;
> >   stream.avail_out = iftmp.0_11;
> >   left_37 = left_8 - _18;
> > 
> > while .SAT_TRUNC somehow interferes with this optimization to produce:
> > 
> >   <bb 5> [local count: 536870912]:
> >   _45 = MIN_EXPR <left_8, 4294967295>;
> >   iftmp.0_11 = .SAT_TRUNC (left_8);
> >   stream.avail_out = iftmp.0_11;
> >   left_37 = left_8 - _45;
> 
> it looks like whatever recognizes .SAT_TRUNC doesn't pay attention that
> there are other uses of the MIN_EXPR and thus the MIN_EXPR stays live.
> 
> IIRC :s on (match (...) is ignored (and that's good IMO) at the moment so
> the user of the match predicate has to check.

Thanks Richard.
Yes, the .SAT_TRUNC doesn't pay any attention the other possible use of
MIN_EXPR.

As your suggestion, we may need one additional check here (like
gimple_unsigned_sat_trunc() && no_other_MIN_EXPR_use_after_sat_trunc_p ())
before we build the SAT_TRUNC call.
Sorry I didn't get the point here why we need to do this, could you please
help to explain a bit more about it? Like wrong code or something else in above
sample code.