[Bug target/54089] [SH] Refactor shift patterns

["olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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?