This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Dominance related breakage, was Re: [PATCH] PR71275 ira.c bb_loop_depth
- From: Alan Modra <amodra at gmail dot com>
- To: Vladimir Makarov <vmakarov at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 27 May 2016 11:44:48 +0930
- Subject: Dominance related breakage, was Re: [PATCH] PR71275 ira.c bb_loop_depth
- Authentication-results: sourceware.org; auth=none
- References: <20160526110205 dot GJ3300 at bubble dot grove dot modra dot org> <5747043E dot 8090701 at redhat dot com>
On Thu, May 26, 2016 at 10:12:14AM -0400, Vladimir Makarov wrote:
> On 05/26/2016 07:02 AM, Alan Modra wrote:
> >This fixes lack of bb_loop_depth info in some of the early parts of
> >ira, which has been the case for quite some time. All active branches
> >return 0 from bb_loop_depth() in update_equiv_regs, but whether that
> >actually causes mis-optimization anywhere but trunk is yet to be
> >determined.
> >
> >I played a little with trying to consolidate this loop_optimizer_init
> >call with one that occurs a little later, but ran into ICEs. (We now
> >have four calls to loop_optimizer_init in ira.c.)
> >
> >Bootstrapped and regression tested powerpc64le-linux and x86_64-linux.
> >OK to apply?
> >
> Yes. Thank you, Alan.
Hi Vlad,
Sorry to do this to you and others, but the patch (committed as
r236789) may be wrong. I didn't see any problems on trunk but when
I backported to gcc-5, I hit an error in stage2 compiling
insn-recog.c "dominator of 10 status unknown" from if_after_reload.
On gcc-5, the error disappears by adding a call to
free_dominance_info (CDI_DOMINATORS);
after the newly added call to loop_optimizer_finalize.
I'm not sure yet what is going on. Does anyone know whether the
free_dominance_info call is needed on trunk?
--
Alan Modra
Australia Development Lab, IBM