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.
