[Bug tree-optimization/45397] [5/6/7 Regression] Issues with integer narrowing conversions

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #23)
> The model of shortening as much as possible for gimple, then widening to
> word mode at the gimple/RTL boundary is probably too simplistic.  We really
> need the ability to widen when doing so allows for simplification.

But the key point here is "when doing so allows for simplification" ...

> That's what the prototype pattern I posted was meant to show.  By widening
> we can expose the common subexpressions, and once the common subexpressions
> are exposed, min/max can do its job.  The problem is we don't have range
> data, so we have to do masking of the result, nor do we know if the widened
> operand is a common subexpression or not.  Thus profitability is unknown at
> transformation time.
> 
> I was about to write off VRP again because it lacks much of the CSE
> capability we want, but VRP has the information to know that the result is
> value preserving if done in the wider mode.  So at VRP time we could do the
> widening without needing to mask the result, at which point widening is
> known to be profitable.  As written we have two casts + addition.  VRP could
> turn that into a addition with a single cast (both of which are common
> subexpressions, but VRP doesn't need to detect that to ensure profitability).
> 
> DOM/FRE have CSE infrastructure, but the range data presented to them is not
> path sensitive and thus useless in this case.

Note that mid-term I'd like our value-numbering infrastructure (VRP is also
a kind of value-numbering) to improve to a point where we simply do VRP
alongside CSE, constant, copy and known-zero/one-bits propagation.  You
"simply" track multiple lattices (configurable) from a common iteration
(configurable as either non-iterating, pessimistically handling backedges,
or iterating, optimistically handling them).

> I'm hesitant to try to do all this in phi-opt -- phi-opt would have to look
> through the casts, prove equivalences, etc.  ick.

Yeah, ICK.  But still this case is very much about pattern matching
(and getting min/max in the end).  It _is_ a saturating operation which
might be common enough to pattern-match (heh, some targets even have
instruction support for them and the middle-end has saturating types!)

So short-term pattern matching in phiopt is the way to go (I'd consider
that even as a regression fix).