[Bug target/40487] Extra zero extensions produced for ARM.
--- Comment #12 from rearnsha at gcc dot gnu dot org 2009-07-15 10:31 --- Fixed with: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00848.html -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug target/40487] Extra zero extensions produced for ARM.
--- Comment #13 from bonzini at gnu dot org 2009-07-15 16:20 --- For the record, it's actually somewhat related to PR39726 (a m68k pessimization), not PR39715. However, because of the way combine canonicalizes the resulting expression, the patch for that bug does not fix the testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug target/40487] Extra zero extensions produced for ARM.
--- Comment #9 from ramana at gcc dot gnu dot org 2009-06-23 09:16 --- (In reply to comment #4) (In reply to comment #3) Is this related to bug 39715? Maybe. 39715 appears to be strictly a 4.5 missed optimization, but from comment #5 it appears as though this is different and I can verify that the same problem exists for 4.3 and trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug target/40487] Extra zero extensions produced for ARM.
--- Comment #10 from steven at gcc dot gnu dot org 2009-06-23 09:50 --- Yes, this bug is indeed not related to bug 39715. I have also verified that the SEE pass (sign-extend elimination, but also should handle zero-extend) fails to handle this case. And that pass doesn't exist anymore on the trunk anyway. I wonder if we can optimize this in GIMPLE already... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug target/40487] Extra zero extensions produced for ARM.
-- ramana at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ramana at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-06-22 16:47:08 |2009-06-23 12:38:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug target/40487] Extra zero extensions produced for ARM.
--- Comment #3 from steven at gcc dot gnu dot org 2009-06-22 16:36 --- Is this related to bug 39715? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug target/40487] Extra zero extensions produced for ARM.
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-22 16:47:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug target/40487] Extra zero extensions produced for ARM.
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-06-22 17:00 --- (In reply to comment #3) Is this related to bug 39715? Maybe. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug target/40487] Extra zero extensions produced for ARM.
--- Comment #5 from steven at gcc dot gnu dot org 2009-06-22 17:58 --- Compiling with gcc 4.4.1 with options -Os -mtune=cortex-a8 I get this: .cpu arm7tdmi .fpu softvfp .eabi_attribute 20, 1 .eabi_attribute 21, 1 .eabi_attribute 23, 3 .eabi_attribute 24, 1 .eabi_attribute 25, 1 .eabi_attribute 26, 1 .eabi_attribute 30, 4 .eabi_attribute 18, 4 .file PR40487.c .text .align 2 .global foo .type foo, %function foo: @ Function supports interworking. @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. add r3, r0, #5 eor r3, r3, r0 and r3, r3, #255 eor r3, r3, r3, asl #2 and r3, r3, #255 eor r3, r3, r3, asl #1 and r0, r3, #255 bx lr .size foo, .-foo .ident GCC: (GNU) 4.4.1 20090622 (prerelease) [gcc-4_4-branch revision 148809] which isn't a whole lot better, is it... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug target/40487] Extra zero extensions produced for ARM.
--- Comment #6 from steven at gcc dot gnu dot org 2009-06-22 18:25 --- I get the same code with 4.5-today as the code of comment #5. I configured for --target=arm-eabi. Should I configure differently to see the shifts instead of ands? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug target/40487] Extra zero extensions produced for ARM.
--- Comment #7 from steven at gcc dot gnu dot org 2009-06-22 18:25 --- see the uxtbs instead of the ands, that is... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug target/40487] Extra zero extensions produced for ARM.
--- Comment #8 from ramana at gcc dot gnu dot org 2009-06-22 22:57 --- (In reply to comment #5) Compiling with gcc 4.4.1 with options -Os -mtune=cortex-a8 I get this: Try with -mcpu=cortex-a8 . -mtune=cortex-a8 doesn't choose the cpu for that , insn selection for the arm port happens with mcpu and tuning and costs are controlled by mtune. And no it isn't a whole load better :) I had configured the toolchain with --with-cpu=cortex-a8. Thanks, Ramana -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug target/40487] Extra zero extensions produced for ARM.
--- Comment #1 from ramana at gcc dot gnu dot org 2009-06-18 12:58 --- I'm not sure about the best way of fixing this without looking at bigger trees at expand time or for combine to be able to do something smart about this one. Essentially you fold the previous zero extension with the current operation because the current operation doesn't care about the higher order bits and there is a zero extension afterwards that puts it into the right shape. x = zextb (y) z = x ^ (x #n) w = zextb (z) into x = y ^ (y #n) w = zextb (x) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug target/40487] Extra zero extensions produced for ARM.
--- Comment #2 from steven at gcc dot gnu dot org 2009-06-18 14:00 --- Why does the zero-bits machinery in combine not make these redundant extensions go away? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
