On 27 March 2013 10:10, Richard Biener <richard.guent...@gmail.com> wrote: > On Tue, Mar 26, 2013 at 6:55 PM, Frederic Riss <frederic.r...@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
