https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42612
--- Comment #7 from Andrew Pinski ---
(In reply to Dmitry Baksheev from comment #6)
> Please consider fixing this issue. Here is another example where not using
> post-increment for loops produces suboptimal code on AArch64. The code is 4x
> slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42612
Dmitry Baksheev changed:
What|Removed |Added
CC||bd at mail dot ru
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42612
--- Comment #5 from Oleg Endo ---
There is a GSoC 2015 project which will try to address the AMS problem.
https://www.google-melange.com/gsoc/project/details/google/gsoc2015/erikvarga/5693417237512192
It will be initially for SH. If it works ou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42612
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
Known to fai
--- Comment #3 from jon at beniston dot com 2010-01-05 12:13 ---
GCC 4.1.2 seems to produce the same code.
mov r2, #0
mov r3, r0
strbr2, [r3], #1
strbr2, [r0, #1]
add r0, r3, #2
@ lr needed for prologue
strbr2, [r3
--- Comment #2 from bonzini at gnu dot org 2010-01-05 11:43 ---
Combine is doing what it knows best (forming complicated instructions,
addressing modes in this case); to do this it is already damaging the nice
shape of the code after the tree optimizers, and synthesizing things like x+2.
--- Comment #1 from steven at gcc dot gnu dot org 2010-01-04 18:53 ---
>From the tree optimizers we go to expand with the following code (from
PR42612.c.139t.optimized):
;; Function func (func)
func (char * p)
{
:
*p_1(D) = 0;
p_2 = p_1(D) + 1;
*p_2 = 0;
p_3 = p_2 + 1;
*p_3 =
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Component|c |rtl-optim
