Really sorry for missing this PR -- don't know that happened :-( Jakub Jelinek <ja...@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