--- Comment #11 from jingyu at google dot com 2010-01-14 00:13 ---
Subject: Re: problematic REG_EQUAL note added to
SUBREG
> Yes, jumping to validate_replacement means that the other combinations are not
> tried. If the new pattern is not valid, the code will try to massage i
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2010-01-13 23:27
---
> Otherwise, I would simply remove this comment.
Fine with me, it's indeed a little confusing.
> I does hunk #3, because I am not sure if all combination results from
> case2 would pass "recog_for_combine". If
--- Comment #9 from jingyu at google dot com 2010-01-13 22:56 ---
Subject: Re: problematic REG_EQUAL note added to
SUBREG
On Wed, Jan 13, 2010 at 2:03 AM, ebotcazou at gcc dot gnu dot org
wrote:
>
>
> --- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-01-13 10:03
--- Comment #8 from jingyu at google dot com 2010-01-13 20:03 ---
Yes. This is a regression from 4.2.1. I have not tried 4.3.x. But at least,
gcc-4.2.1 works correctly.
The following assembly is compiled out of gcc-4.2.1 with -mthumb -Os.
ldr r3, .L14+8
ldr r
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-01-13 10:03
---
> This patch fixes the bug.
> Do you think if this patch is favorable? If yes, I will do dejagnu
> test and send it to gcc-patches for review.
The patch is probably correct, but I'd ditch hunks #1 and #3. In cas
--- Comment #6 from jingyu at google dot com 2010-01-13 01:18 ---
Subject: Re: problematic REG_EQUAL note added to
SUBREG
> We should try and set changed_i3_dest to 1 in this particular case as well.
Here is the patch which only changes changed_i3_dest for two
particular case
--- Comment #5 from jingyu at google dot com 2010-01-12 22:21 ---
Subject: Re: problematic REG_EQUAL note added to
SUBREG
On Tue, Jan 12, 2010 at 12:57 AM, ebotcazou at gcc dot gnu dot org
wrote:
>
>
> --- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-01-12 08:57
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-01-12 08:57
---
> Then gcc comes to line3657. Since changed_i3_dest is 0, gcc does not
> call adjust_for_new_dest at all.
>
> line3657:
> if (changed_i3_dest)
> {
> PATTERN (i3) = newpat;
> adjust_for_new_dest (i
--- Comment #3 from jingyu at google dot com 2010-01-12 02:45 ---
Subject: Re: problematic REG_EQUAL note added to
SUBREG
On Mon, Jan 11, 2010 at 2:00 PM, ebotcazou at gcc dot gnu dot org
wrote:
>
>
> --- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-01-11 22:00
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-01-11 22:00
---
The REG_EQUAL note is correct after fwprop but not after combine, so the
problem lies in combine. The note should have been removed by
adjust_for_new_dest since the destination of I3 has changed.
--
ebotcazou
11 matches
Mail list logo
