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

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089

--- Comment #29 from Oleg Endo <olegendo at gcc dot gnu.org> 2013-02-16 11:36:37 UTC ---
Another case taken from CSiBE / bzip2, where reusing the intermediate shift
result would be better:

void uInt64_from_UInt32s ( UInt64* n, UInt32 lo32, UInt32 hi32 )
{
   n->b[7] = (UChar)((hi32 >> 24) & 0xFF);
   n->b[6] = (UChar)((hi32 >> 16) & 0xFF);
   n->b[5] = (UChar)((hi32 >> 8) & 0xFF);
   n->b[4] = (UChar) (hi32 & 0xFF);
/*
   n->b[3] = (UChar)((lo32 >> 24) & 0xFF);
   n->b[2] = (UChar)((lo32 >> 16) & 0xFF);
   n->b[1] = (UChar)((lo32 >> 8) & 0xFF);
   n->b[0] = (UChar) (lo32 & 0xFF);
*/
}

on rev 196091 with -O2 -m4 compiles to:

        mov     r6,r0
        shlr16  r0
        shlr8   r0
        mov.b   r0,@(7,r4)
        mov     r6,r0
        shlr16  r0
        mov.b   r0,@(6,r4)
        mov     r6,r0
        shlr8   r0
        mov.b   r0,@(5,r4)
        mov     r6,r0
    mov.b   r0,@(4,r4)

which would be better as:
        mov     r6,r0
        mov.b   r0,@(4,r4)
        shlr8   r0
        mov.b   r0,@(5,r4)
        shlr8   r0
        mov.b   r0,@(6,r4)
        shlr8   r0
        mov.b   r0,@(7,r4)

this would require reordering of the mem stores, which should be OK to do if
the mem is not volatile.  

Reordering the stores manually:

void uInt64_from_UInt32s ( UInt64* n, UInt32 lo32, UInt32 hi32 )
{
   n->b[4] = (UChar) (hi32 & 0xFF);
   n->b[5] = (UChar)((hi32 >> 8) & 0xFF);
   n->b[6] = (UChar)((hi32 >> 16) & 0xFF);
   n->b[7] = (UChar)((hi32 >> 24) & 0xFF);
}

still results in:

        mov     r6,r0
        mov.b   r0,@(4,r4)
        mov     r6,r0
        shlr8   r0
        mov.b   r0,@(5,r4)
        mov     r6,r0
        shlr16  r0
        mov.b   r0,@(6,r4)
        mov     r6,r0
        shlr16  r0
        shlr8   r0
        mov.b   r0,@(7,r4)

... at least this case should be handled, I think.