This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] pr70890, r235660 miscompiles stage2
- From: Alan Modra <amodra at gmail dot com>
- To: Bernd Schmidt <bschmidt at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 3 May 2016 22:54:18 +0930
- Subject: Re: [PATCH] pr70890, r235660 miscompiles stage2
- Authentication-results: sourceware.org; auth=none
- References: <20160503104535 dot GH18915 at bubble dot grove dot modra dot org> <57288660 dot 4060305 at redhat dot com> <20160503122024 dot GL18915 at bubble dot grove dot modra dot org> <57289AA0 dot 9010000 at redhat dot com>
On Tue, May 03, 2016 at 02:33:36PM +0200, Bernd Schmidt wrote:
> On 05/03/2016 02:20 PM, Alan Modra wrote:
> >>
> >>>diff --git a/gcc/ira.c b/gcc/ira.c
> >>>index a38e67e..cf5be35 100644
> >>>--- a/gcc/ira.c
> >>>+++ b/gcc/ira.c
> >>>@@ -3742,6 +3742,16 @@ combine_and_move_insns (void)
> >>> if (use_insn == BB_HEAD (use_bb))
> >>> BB_HEAD (use_bb) = new_insn;
> >>>
> >>>+ /* Since regno now dies in use_insn we can't leave any
> >>>+ equivalence for a reg set by use_insn as the equivalence
> >>>+ must reference regno. */
> >>
> >>"now dies" is the first part that I stumbled over. Doesn't it die there
> >>regardless of the move?
> >
> >Yes, but DF doesn't seem to see that.. If the def insn was left in
> >its original bb we have the reg live practically everywhere. Search
> >for "DI 1381" in attached pre-patch dumps.
>
> Ok, we have blocks 160 -> 43 -> 44, all of which have loop depth of 0, so it
Err, is loop depth accurate in 254r.sched1?
In the ira dump, I see them all at loop depth 1.
So I expect that DF doesn't see the death because we're in a loop.
> looks like we should have a death note? I could see how such a move would
> create a new death if the def was moved into a loop from outside.
We won't move into a loop from outside.
if (bb_loop_depth (use_bb) > bb_loop_depth (def_bb))
continue;
--
Alan Modra
Australia Development Lab, IBM