http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
Oleg Endo <olegendo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kkojima at gcc dot gnu.org
--- Comment #4 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-08-09 21:54:42
UTC ---
I'm currently playing around with the macro SHIFT_COUNT_TRUNCATED (sh.h) and
the target hook TARGET_SHIFT_TRUNCATION_MASK (which is not implemented yet).
Doing the following on rev 190259 (which is actually wrong):
sh.h:
-#define SHIFT_COUNT_TRUNCATED (! TARGET_SH3 && ! TARGET_SH2A)
+#define SHIFT_COUNT_TRUNCATED (1)
sh.c:
+/* Implement the TARGET_SHIFT_TRUNCATION_MASK target hook. */
+
+#undef TARGET_SHIFT_TRUNCATION_MASK
+#define TARGET_SHIFT_TRUNCATION_MASK sh_shift_truncation_mask
+
+static unsigned HOST_WIDE_INT
+sh_shift_truncation_mask (enum machine_mode mode)
+{
+ int bitsize = GET_MODE_BIT_SIZE (mode);
+
+ if (TARGET_SHMEDIA)
+ return bitsize - 1;
+
+ return MAX (32, bitsize) - 1;
+}
... and looking at some CSiBE size results, I see the a couple of weird cases
similar to what happens to the set_bh_page function in
linux-2.4.23-pre3-testplatform/fs/buffer.c.
Without the changes:
...
.L592:
mov.l .L598,r1 !!
mov r9,r3
mov.l @r1,r2 !! r2 = zone_table[0]
add #124,r2
mov.l @(36,r2),r1
mov.l @(32,r2),r2
add r10,r1
mov.l r9,@(56,r8)
sub r2,r3
mov r3,r2
mov.l .L599,r3
shar r2
shar r2
mul.l r3,r2
mov #12,r3
sts macl,r2
shld r3,r2
add r2,r1
mov.l r1,@(52,r8)
With the changes:
...
.L592:
mov.l @(24,r8),r0 !!
mov r8,r3
mov.l .L598,r1
shlr16 r0 !!
shlr8 r0 !!
shll2 r0 !!
mov.l @(r0,r1),r2 !! r2 = zone_table[page->flags >> ZONE_SHIFT]
add #124,r2
mov.l @(36,r2),r1
mov.l @(32,r2),r2
add r10,r1
mov.l r8,@(56,r9)
sub r2,r3
mov r3,r2
mov.l .L599,r3
shar r2
shar r2
mul.l r3,r2
mov #12,r3
sts macl,r2
shld r3,r2
add r2,r1
mov.l r1,@(52,r9)
It seems that without the (wrong) patch, the index in the inline function
'page_zone' is reduced from 'page->flags >> ZONE_SHIFT' to '0', and thus the
resulting code is wrong?!
I've tried to reproduce this in an isolated test case but couldn't get it to do
the same - the generated code seems always correct, with and without the
changes.
I'm confused... Kaz, do you have any idea what could be going on there?
