[Bug target/55303] [SH] Add support for clips / clipu instructions

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

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

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2013-03-02
         AssignedTo|unassigned at gcc dot       |olegendo at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #1 from Oleg Endo <olegendo at gcc dot gnu.org> 2013-03-02 16:16:41 UTC ---
Created attachment 29567
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29567
Working patch with a thinko.

This patch, albeit working, has a thinko.
The idea was to reduce the constraints of the clips/clipu insn comparison
constants by adding/subtracting a constant offset value before/after the actual
clipping insn.  For example:

int
test_02 (int a)
{
  return max (0, min (255, a));
}

becomes:

_test_02:
        movi20  #128,r1
        sub     r1,r4
        mov     r4,r0
        clips.b r0
        rts
        add     r1,r0

The problem with this is that it won't work for values that will wrap-around
before/after the offset subtraction/addition.

E.g. plugging the value 0x80000000 (−2147483648) into the above case:

        movi20  #128,r1
        sub     r1,r4     // r4 =  0x80000000 - 128 = 0x7FFFFF80
        mov     r4,r0
        clips.b r0        // !(r0 < -128) && (r0 > 127) -> r0 = 127
        rts
        add     r1,r0     // r0 = 127 + 128 = 255
                          // expected result: 0

Maybe this case could be handled by using subv/addv insns to catch
over/underflows somehow, but probably the resulting code would be more complex
(and thus slower) than two straight forward compare-and-branch sequences.

On the other hand, if it is known that the input value is in a certain range
(e.g. a sign/zero extended HImode or QImode), the offset approach should work
fine.

I will modify the attached patch so that it will allow only the HW clip
constants for now.