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.
