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

[Jakub Jelinek <jakub@redhat.com>]

On Wed, Nov 22, 2017 at 01:03:06PM +0000, Richard Sandiford wrote:
> Richard Biener <rguenther@suse.de> writes:
> > On Wed, 22 Nov 2017, Jakub Jelinek wrote:
> >
> >> On Wed, Nov 22, 2017 at 10:41:19AM +0100, Richard Biener wrote:
> >> > How much churn would it be to pass down a mode alongside the operands
> >> > in expand_binop?  Can't find it right now but didn't we introduce
> >> > some rtx_with_mode pair-like stuff somewhen?
> >> 
> >> We have rtx_mode_t for that.  But there are 240+ calls to expand_binop,
> >> and even if we add an overload that will transform it, unless we forcefully
> >> inline it wouldn't that slow down all the spots a little bit?
> >> The thing is, for the vast majority of binary ops we don't need the operand
> >> modes, it is mainly comparisons, second arg of shifts/rotates and this
> >> widening case.
> >
> > Ok, so maybe split expand_binop then to the class of cases where we do
> > need the mode and a class where we don't then?
> >
> > We don't have to use rtx_mode_t we can just pass two arguments.  Not
> > sure what is more convenient to use.
> 
> FWIW, rtx_mode_t was only really added so that we have a single blob
> for wi:: calls (with the hope that it would eventually be replaced
> with just the rtx once CONST_INTs have a mode).  I think it'd be
> more consistent to use separate arguments for other cases.

So perhaps it would be easiest to just add one defaulted to VOIDmode
argument to expand_binop, say aux_mode, which would stand for whatever
other second mode the optab needs (could be operand mode for comparisons
or the widening stuff, or op1 mode for shifts, etc.).  If it is VOIDmode,
it wouldn't be used.

	Jakub