This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: expmed.c cost calculation limited to word size
- From: Frederic Riss <frederic dot riss at gmail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: gcc <gcc at gcc dot gnu dot org>
- Date: Wed, 27 Mar 2013 11:21:20 +0100
- Subject: Re: expmed.c cost calculation limited to word size
- References: <CAKk_3s_dcXHy9zr9JJWiE3xdi+up6UYEZDjQEv20QcB92vKc9w at mail dot gmail dot com> <CAFiYyc3BpKVgN4THYsrqudG6SNKnZr3_JVpakPbOawjZPmfjPA at mail dot gmail dot com>
On 27 March 2013 10:10, Richard Biener <richard.guenther@gmail.com> wrote:
> On Tue, Mar 26, 2013 at 6:55 PM, Frederic Riss <frederic.riss@gmail.com> wrote:
>> The cost arrays are filled up to
>> MAX_BITS_PER_WORD, thus as a temporary workaround I have defined
>> MAX_BITS_PER_WORD to 64, and I have softened the checks to fail only
>> above MAX_BITS_PER_WORD. This allows my 32bits backend to specify that
>> it wants these optimizations to take place for 64bits arithmetic.
>>
>> What do people think about this approach? does it make sense?
>
> Another approach would be to simply use the cost of a BITS_PER_WORD
> shift for bigger shifts. Adjusting MAX_BITS_PER_WORD sounds like a hack
> to me.
That's what I had done at first. Works also for me, but I thought it
was a bit too artificial compared to using a computed value (Even
though I agree that a DImode 33 bits shift is more than likely to have
the same cost as a 30 bits one).
> Note that on trunk I see the cost arrays are now inline functions, so things
> may have changed for the better already.
I'll have a look at the new code. Thanks for the comments !
Fred