Re: [PATCH] Fix mult expansion ICE (PR middle-end/82875)

[Richard Sandiford <richard dot sandiford at linaro dot org>]

Really sorry for missing this PR -- don't know that happened :-(

Jakub Jelinek <jakub@redhat.com> writes:
> On these two testcases, we end up expanding MULT_EXPR where both arguments
> end up being VOIDmode.  For smul_optab that isn't a problem, we have
> the mode next to it, but in some cases we want to use {u,s}mul_widen_optab
> which is a conversion optab which needs two modes expand_binop is called
> just with one mode, the result mode, so the other mode is guessed from
> the operands and if both are VOIDmode, then a fallback is chosen to use
> return mode.  The new find_widening* changes ICE on that though, previously
> we'd just do something.

What do you think about passing the modes of the operands down to
expand_binop too, a bit like simplify_unary_operation?  We could have
an overloaded wrapper with the current interface to avoid updating every
caller.  That at least would cut down on some of the guessing that
the function currently does.

I can have a go at that if it sounds OK, but the posted patch LGTM too
as an alternative.

> In any case, I think we need to make sure this doesn't happen while we
> still know both modes for the {u,s}mul_widen_optab.  Bootstrapped/regtested
> on x86_64-linux and i686-linux, ok for trunk?
>
> Perhaps additionally we could have somewhere a case which for both arguments
> constant (unlikely case, as the gimple optimizers should usually optimize
> that out) and selected optabs for which we know the corresponding RTL code
> we could use simplify_const_binary_operation and see if it optimizes into a
> constant and just return that.  Though, these functions are large and it
> is still possible a constant could be uncovered later, so I think we want
> this patch even if we do something like that.

(FWIW, I agree we need this either way, although folding sounds good too.)

Thanks,
Richard