This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Fixed-point patch 8/10
- From: Mark Mitchell <mark at codesourcery dot com>
- To: "Fu\, Chao-Ying" <fu at mips dot com>, gcc-patches at gcc dot gnu dot org, Mark Mitchell <mark at codesourcery dot com>, "Thekkath\, Radhika" <radhika at mips dot com>, "Stephens\, Nigel" <nigel at mips dot com>, richard at codesourcery dot com
- Date: Tue, 11 Sep 2007 14:43:51 -0700
- Subject: Re: [patch] Fixed-point patch 8/10
- References: <3CB54817FDF733459B230DD27C690CEC03EE8F30@Exchange.mips.com> <871wd51uen.fsf@firetop.home>
Richard Sandiford wrote:
>> And, maybe some targets don't want to do this, due to the cost of
>> saturating instructions. So, the target-independent code may need to
>> check the cost to see if it is beneficial.
>
> But AIUI, your patch is short-circuiting the target-independent code
> that decomposes a vector operation into individual elementwise operations.
> Is that right? If so, it seems very unlikely that a target would provide
> a saturating vector addition that's _more_ expensive than decomposing a
> vector into elements, performing addition on each pair of elements,
> and reconstituting the vector.
FWIW, I agree with Richard here. This seems like something that would
best be done as a target-independent optimization. If, at some future
point, it turns out that there's a target for which this is not a win,
we can always introduce a hook. But, just as we recently did with
ffs/clz/etc., there's a class of optimizations that are very broadly
applicable, and we might as well have that benefit on all targets.
Thanks,
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713