https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40730
--- Comment #15 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #14)
> Fixed for GCC 12 by r12-897-gde56f95afaaa22 (and r11-408-g84935c9822183c).
The first redundant load was fixed by r11-408-g84935c9822183c.
The extra store was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40730
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40730
Steven Bosscher changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|steven at gcc d
--- Comment #12 from carrot at google dot com 2010-01-11 08:55 ---
(In reply to comment #11)
> Yes, I would have expected the block starting with .L4 to be *after*
> the block starting with .L5, something like so:
>
> iterate:
> push{lr}
> ldr r3, [r1]
> .L6:
>
--- Comment #11 from stevenb dot gcc at gmail dot com 2010-01-11 08:22
---
Subject: Re: redundant memory load
On Mon, Jan 11, 2010 at 7:47 AM, carrot at google dot com
wrote:
>> iterate:
>> push{lr}
>> ldr r3, [r1]
>> .L6:
>> str r3, [r0]
>>
--- Comment #10 from carrot at google dot com 2010-01-11 06:47 ---
(In reply to comment #9)
> With "GCC: (GNU) 4.5.0 20100108 (experimental) [trunk revision 155731]" and my
> patch for bug 20070 applied, I get the following code:
>
> iterate:
> push{lr}
> ldr r3,
--- Comment #9 from steven at gcc dot gnu dot org 2010-01-08 09:34 ---
With "GCC: (GNU) 4.5.0 20100108 (experimental) [trunk revision 155731]" and my
patch for bug 20070 applied, I get the following code:
iterate:
push{lr}
ldr r3, [r1]
.L6:
str r3, [r
--- Comment #8 from steven at gcc dot gnu dot org 2009-07-15 09:47 ---
That redundant move has to be a separate issue, indeed. I would expect the
register allocator to coalesce those registers.
I hadn't expected this. I thought the result would be just the removal of the
redundant loa
--- Comment #7 from carrot at google dot com 2009-07-15 08:07 ---
(In reply to comment #6)
> Carrot, can you please try this test case with my patch
> "crossjump_abstract.diff" from Bug 20070 applied?
>
I tried your patch. It did remove the redundant memory load. Following is the
outpu
--- Comment #6 from steven at gcc dot gnu dot org 2009-07-14 09:20 ---
Carrot, can you please try this test case with my patch
"crossjump_abstract.diff" from Bug 20070 applied?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40730
--- Comment #5 from steven at gcc dot gnu dot org 2009-07-14 09:18 ---
As you said, try_crossjump_bb tries to find the same instruction sequence in
*all* predecessors of a basic block bb. Meaning that the load must have been
redundant even before cross jumping occurred.
If you are right
--- Comment #4 from carrot at google dot com 2009-07-14 09:14 ---
In TREE level, the two stores are different statements. Only after register
allocation, the two stores get same register and make the load redundant.
try_crossjump_bb tries to find same instruction sequence in all predece
--- Comment #3 from steven at gcc dot gnu dot org 2009-07-13 10:10 ---
And no, it is *not* OK to remove this kind of redundant code in DCE. The load
may be redundant, but it is not dead.
It is not clear to me why cleanup_cfg would move that insn. Perhaps you can
show what is going on
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-13 09:50 ---
-fgcse-las should do the trick. Note that PRE would do this kind of
optimization on the tree-level, but it is disabled with -Os (so is gcse).
:
D.1614_2 = p2_1(D)->front;
p1_3(D)->head = D.1614_2;
goto ;
:
--- Comment #1 from carrot at google dot com 2009-07-13 08:58 ---
Created an attachment (id=18183)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18183&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40730
15 matches
Mail list logo
