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.
