http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50110
David Meggy <david.meggy at icron dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
--- Comment #5 from David Meggy <david.meggy at icron dot com> 2012-01-10
19:16:15 UTC ---
Let me sum up this bug. It boiled down to a misunderstanding of how bit field
extract works on a big endian processor (I don't know if anyone else has
implemented this on a big endian processor). Since we have implemented the
starting bit in our hardware from the least significant bit, I've just modified
the output instruction to change the start bit to the least significant bit.
(define_insn "extzvsi"
[(set (match_operand:SI 0 "register_operand" "=r")
(zero_extract:SI (match_operand:SI 1 "register_operand" "r")
(match_operand 2 "const_int_operand" "")
(match_operand 3 "const_int_operand" "")))]
""
"ext\t%1,%2,32 - %2 - %3,%0"
)
This works quite well for us, and is giving us the code space savings we were
looking for, an ~1% code space reduction. Not bad for a tiny GCC patch, tiny
binutils patch, and a minor CPU opcode addition.
This bug can be closed. Marking as RESOLVED - INVALID, as it isn't a real bug,
but a documentation misunderstanding
