This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/50110] Endian reversal when adding extzv instruction
- From: "david.meggy at icron dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 10 Jan 2012 19:16:15 +0000
- Subject: [Bug rtl-optimization/50110] Endian reversal when adding extzv instruction
- Auto-submitted: auto-generated
- References: <bug-50110-4@http.gcc.gnu.org/bugzilla/>
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