This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Dominance related breakage, was Re: [PATCH] PR71275 ira.c bb_loop_depth


On 05/26/2016 10:14 PM, Alan Modra wrote:
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?

That is ok. It is always a discovery. I am not sure but I think I saw this problem when I wrote IRA.

Looking at the dominance code, I seems to me that it can reuse the previous info if it was not cleared. So I guess free_dominance_info is important.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]