[Bug target/40457] use stm and ldm to access consecutive memory words
--- Comment #6 from rearnsha at arm dot com 2009-06-17 08:40 ---
Subject: Re: use stm and ldm to access consecutive
memory words
> --- Comment #5 from ubizjak at gmail dot com 2009-06-16 18:16 ---
> Registers also need to be consecutive, starting from certain register, i.e.:
>
> str r1, [r0]
> str r2, [r0, #4]
No, register numbers simply need to be ascending and loaded from
consecutive memory addresses, so {r0, r2, r3, r5} is valid, but {r2, r5,
r0, r3} is not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40457
[Bug target/40657] allocate local variables with fewer instructions
--- Comment #6 from rearnsha at arm dot com 2009-07-13 14:22 ---
Subject: Re: allocate local variables with fewer
instructions
On Mon, 2009-07-06 at 10:43 +, steven at gcc dot gnu dot org wrote:
> But how to do this in GCC... The "push {lr}" is never even in the
> RTL. Output with same options + "-dAP":
We already do this for ARM state. In thumb the split between epilogue
code in RTL and text makes it slightly more complex, but not massively
so.
R.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40657
[Bug c/28568] compiler generates incorrect ARM instructions when using long bitfields
--- Comment #6 from rearnsha at arm dot com 2006-09-11 12:14 --- Subject: Re: compiler generates incorrect ARM instructions when using long bitfields On Wed, 2006-08-02 at 13:56, jason dot morgan at vpnsolutions dot uk dot com wrote: > Where do I obtain EABI and what effect will it have on my toolchain? http://www.arm.com/products/DevTools/ABI.html > Is there any plan or project to merge the resolution to PR23623 back into gcc > 4.1.1 No, this doesn't fit the critera for a regression, so it won't be fixed in FSF releases. However, I think the CodeSourcery distributions have this feature in a 4.1 build. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28568
[Bug rtl-optimization/38644] [4.4/4.5/4.6/4.7 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644 --- Comment #48 from Richard Earnshaw 2011-09-12 15:31:51 UTC --- On 12/09/11 16:18, law at redhat dot com wrote: > A much simpler way to fix this is to emit a barrier just prior to > mucking around with stack pointer in the epilogue. That's how targets > have dealt with this exact issue for a couple decades. Simpler, but wrong. The compiler should not be generating unsafe code by default. The problem is in the mid-end and expecting every port to get this right in order to work-around a mid-end bug is just stupid stupid stupid. The mid end should not be scheduling around stack moves unless it has been explicitly told it is safe to do this. I don't understand why there is so much resistance to fixing the problem properly.
[Bug target/9760] [arm] Combine cannot do its job because immediate operand is used instead of register
--- Comment #8 from rearnsha at arm dot com 2010-02-08 16:30 ---
Subject: Re: [arm] Combine cannot do its job because
immediate operand is used instead of register
On Mon, 2010-02-08 at 16:11 +, steven at gcc dot gnu dot org wrote:
> Can someone please explain what the expected code is?
Something like
stmfd sp!, {r3, r4, r5, lr}
mov r4, r0
mov r5, #255
mov r1, r4, lsr #24
mov r0, #8
bl func
and r1, r5, r4, lsr #16
mov r0, #8
bl func
mov r1, r5, r4, lsr #8
mov r0, #8
ldmfd sp!, {r3, r4, r5, lr}
b func
By putting 255 into a register we add one instruction, but remove 2; so
save one overall. This is one of the rare cases where an immediate is
actually more expensive on ARM than using a register.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9760
[Bug target/9760] [arm] Combine cannot do its job because immediate operand is used instead of register
--- Comment #9 from rearnsha at arm dot com 2010-02-08 16:31 --- Subject: Re: [arm] Combine cannot do its job because immediate operand is used instead of register On Mon, 2010-02-08 at 16:30 +, rearnsha at arm dot com wrote: > mov r1, r5, r4, lsr #8 > Should, of course, be AND. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9760
