[Bug tree-optimization/86628] Missed simplification of division

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2018-07-23
                 CC|                            |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #3)
> We already simplify some simple cases like x*t/t -> x in match.pd. Larger
> cases are for a pass like reassoc. In this particular case, we could also
> imagine somehow noticing that (x*y)*z is better reassociated as x*(y*z)
> because y*z is already computed.

Yeah, generally we can't associate because (x*y)*z may not overflow because
x == 0 but x*(y*z) may because y*z overflows.

I wonder if we have in general ((x*y)*z)*...)*k what it takes to prove
that it is valid to factor out a random pair (already computed elsewhere).
I suppose we have to move that factored pair innermost for the case it
is zero?

Note the reassoc pass doesn't handle TYPE_OVERFLOW_UNDEFINED types at all
at the moment.

> A later pass would then cleanup x*t/t.
> Simplifying the unsigned case looks wrong to me.