On Fri, Mar 13, 2009 at 06:06:41PM +0100, Paolo Bonzini wrote:
>
> >>> Hm. In fold-const.c we try to make sure to produce the same result
> >>> as the target would for constant-folding shifts. Thus, Paolo, I think
> >>> what fold-const.c does is what we should assume for
> >>> !SHIFT_COUNT_TRUNCATED. No?
> >> Unfortunately it is not so simple. fold-const.c is actually wrong, as
> >> witnessed by this program
> >>
> >> static inline int f (int s) { return 2 << s; }
> >> int main () { printf ("%d\n", f(33)); }
> >>
> >> which prints 4 at -O0 and 0 at -O2 on i686-pc-linux-gnu.
> >
> > But this is because i?86 doesn't define SHIFT_COUNT_TRUNCATED, no?
>
> Yes, so fold-const.c is *not* modeling the target in this case.
>
> But on the other hand, this means we can get by with documenting the
> effect of a conservative truncation mask: no wrong code bugs, just
> differences between optimization levels for undefined programs. I'll
> check that the optimizations done based on the truncation mask are all
> conservative or can be made so.
>
> So, I'd still need the information for arm and m68k, because that
> information is about the bitfield instructions. For rs6000 it would be
> nice to see what they do for 64-bits (for 32-bit I know that PowerPCs
> truncate to 6 bits, not 5).
For 64 bit variable rotate/shifts, the count is truncated to 7 bits.
That's consistent on rs6000 in order to simplify the implementation
of double precision shifts (the example code is in some appendices
of the architecture books).
Gabriel
