On Mar 13, 2009, at 10:06 AM, 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). But for the other architectures, we can
be
conservative.
VAX doesn't truncate at all, if you specify >31 bits it raises a
reserved operand exception.
