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: [PATCH] Fix code quality regression on UltraSPARC


> Thanks to the wonders of IRC peer pressure, I decided to read-up
> on cfgloopmanip.c and review your patch.  The good news is that I
> think your patch is OK for mainline, the bad news is that your
> patch no long applies cleanly following Kazu's recent clean-ups to
> create_preheader :<

Thanks for the review.

> Could you revise you patch against current mainline sources and
> resubmit it after benchmarking and regression testing?  Hopefully,
> I should be able to approve it almost straight away.

Yes, I'll do that shortly.

> I also think it should be relatively simple to improve upon your
> preheader placement heuristics.  The ideal block to place the
> newly created preheader after is a predecessor that falls through
> to the loop header.

I presume you meant to the loop preheader?  My understanding is that the only 
predecessor of the header is the preheader once the latter is created.

> You should be able to detect this by checking 
> e->flags & EDGE_FALLTHRU, at which point you can break out of
> your search for best_pred.  What do you think?

I think this will not change anything: if I break out because the predecessor 
is FALLTHRU, this means that I'm the next_bb of this predecessor, so this 
next_bb cannot be another predecessor and the loop will stop at the next 
iteration.  Unless we always scan all the edges until we find the FALLTHRU.
I originally didn't want to, so the proposed heuristics is pretty limited.  
But if you're OK to go that route, it's fine with me.

-- 
Eric Botcazou


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