Re: Fix gcc.dg/lower-subreg-1.c failure

[Hans-Peter Nilsson <hans-peter.nilsson@axis.com>]

> From: Richard Sandiford <rdsandiford@googlemail.com>
> Date: Wed, 9 May 2012 11:14:49 +0200

> Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes:
> >> From: Richard Sandiford <rdsandiford@googlemail.com>
> >> Date: Tue, 1 May 2012 16:46:38 +0200
> >
> >> To repeat: as things stand, very few targets define proper rtx costs
> >> for SET.
> >
> > IMHO it's wrong to start blaming targets when rtx_cost doesn't
> > take the mode in account in the first place, for the default
> > cost.  (Well, except for the modes-tieable subreg special-case.)
> > The targets where an operation in N * word_mode costs no more
> > than one in word_mode, if there even is one, is a minority,
> > let's adjust the defaults to that.
> 
> I'll pass on approving or disapproving this patch, but for the record:
> a factor of word_mode seems a bit too simplistic.

I'd say it's the right level: simplistic enough for the default,
not to mention now linear, without being plainly ignorant as now.

> It's OK for moves
> and logic ops, but addition of multiword modes is a bit more complicated.

How about (same factor) factor*COSTS_N_INSNS (1)*3/2 to account
for carry?  Or is 2*factor a better default?  Further
improvements are welcome, but I see the patch as a strict
improvement and I hope it will not be shot down by requests for
perfection - at least not without detailing said perfection.

> Multiplication and division by multiword modes is even more
> so, of course.

Suggestions are welcome, but in the absence of that, I'd say any
factor larger than one is is a good start, like in the patch.

> > I think there should be a gating check whether the target
> > implements that kind of shift in that mode at all, before
> > checking the cost.  Not sure whether it's generally best to put
> > that test here, or to make the rtx_cost function return the cost
> > of a libcall for that mode when that happens.  Similar for the
> > other insns.
> 
> This has come up a few times in past discussions about rtx_cost
> (as I'm sure you remember :-)).  On the one hand, I agree it might
> be nice to shield the backend from invalid insns.  That would
> effectively mean calling expand on each insn though, which would be
> rather expensive.

No, nothing that complicated.  I'm thinking of just basically
checking that there's an operation in that mode, like:

if (direct_optab_handler (code_to_optab [GET_CODE (x)], mode)
    == CODE_FOR_nothing)
  {
    ... return tabled default cost; for libcall or open-code ...
  }

Restricting the validity-gating to checking that the mode is
valid for the operation wouldn't interfere with fancy pipeline
speculative use.

> So I think this patch is using rtx_cost according to its current
> interface.

The "interface" use previously ignored the mode for most uses
(QED), so that's not completely correct. ;)

> If someone wants to change or restrict that interface,
> than that's a separate change IMO.  And it should be done consistently
> rather than in this one place.
> 
> In this case it doesn't matter anyway.  If we never see a shift
> in mode M by amount X, we'll never need to make a decision about
> whether to split it.

If it's never used, then I don't mind it being wrong if that
simplifies the computation. :)

> > Isn't the below better than doing virtually the same in each
> > target's rtx_costs?
> 
> FWIW, MIPS, SH and x86 all used something slightly different (and more
> complicated).  I imagine PowerPC and SPARC will too.  So "each" seems
> a bit strong.
> 
> That's not an objection to the patch though.  I realise some ports do
> have very regular architectures where every register is the same width
> and has the same move cost.

Hence the default should follow a very regular model...

brgds, H-P