This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fix gcc.dg/lower-subreg-1.c failure
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: rdsandiford at googlemail dot com
- Cc: iant at google dot com, zadeck at naturalbridge dot com, gcc-patches at gcc dot gnu dot org, mikestump at comcast dot net, Kenneth dot Zadeck at naturalbridge dot com, avr at gjlay dot de, ramana dot radhakrishnan at linaro dot org
- Date: Wed, 9 May 2012 18:36:53 +0200
- Subject: Re: Fix gcc.dg/lower-subreg-1.c failure
> 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