On 02/09/2017 11:08 AM, Aldy Hernandez wrote:
For those of you not following the PR, this is a re-post of a patch that
was approved in some form a year+ ago, but was reverted because it
caused an undiagnosed bootstrap problem on AIX:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00421.html
Annoyingly, the AIX problem disappeared with some unrelated changes to
SCCVN by Richard in more recent GCC's. Consequently, the patch got
blocked because we could no longer reproduce the problem, but it wasn't
entirely clear that it was gone.
As penance for sins in a previous life, I have taken it upon myself to
reproduce this problem back in time and find what caused the AIX failure
back then. I will spare the list the boring process, but the problem
with the original patch was that it changed the semantics of
check_simple_exit, but not all of it's indirect callers. This caused
two versions of the same loop to have different unsynchronized iteration
variables-- one in a simple register, and one in a doloop variant on ppc.
I have bootstrapped this patch around trunk@226811 on AIX (all
languages), which is the latest time AIX failed to bootstrap with the
original patch. My testing environment included a handful of other
unrelated changes that were required to coerce AIX into building
GCC5-ish with GCC6.1.
I have also bootstrapped and tested this patch at today's trunk on
x86-64 Linux with no adverse effects.
As I've mentioned, I believe the original patch was previously approved,
so to aid in reviewing I am including the full patch ("full-patch") with
my changes on top of the original patch, as well as an incremental patch
("incremental-patch") with my recent changes to bring AIX to happiness.
I understand if changes to the RTL looping infrastructure are too late
for this release cycle, and as I am not the original author-- don't kill
the messenger! I just want to move this forward, even if it means
getting approval for GCC8. This will at the very least allow me to
sleep at night, knowing I won't have to touch AIX for a while (or at
least wrt to this PR) ;-).
Original author(s) CC'ed.
So it seems in your updated patch there is only one call where we ask
for LOOP_EXIT_COMPLEX, specifically the call from get_loop_location.
But I don't see how asking for LOOP_EXIT_COMPLEX from that location
would change whether or not we unroll any given loop (which is the core
of bz64081).
Am I missing something?
Jeff
