[4.0.0 Release] Release Candidate 2 source and binaries available

Please try it out, run tests, build your favourite projects and file
bugs about anything that needs to be fixed, marking them as blockers
of http://llvm.org/pr31622.

I have encountered very long compile times for three large source files containing generated/unrolled code at -O1.
We are talking about 10+ hours here without completing, so it looks very much like an endless loop.
The processes are using 15, 22 and 27 GB of memory but do not appear to grow further.
This worked fine in the past, so appears to be a regression.

These stacks seem to be prevalent:

#0 0x0000000001850588 in llvm::SUnit::addPred(llvm::SDep const&, bool) ()
#1 0x0000000001855265 in llvm::ScheduleDAGInstrs::addChainDependency(llvm::SUnit*, llvm::SUnit*, unsigned int) ()
#2 0x0000000001855519 in llvm::ScheduleDAGInstrs::addChainDependencies(llvm::SUnit*, llvm::ScheduleDAGInstrs::Value2SUsMap&) ()
#3 0x000000000185f3ba in llvm::ScheduleDAGInstrs::buildSchedGraph(llvm::AAResults*, llvm::RegPressureTracker*, llvm::PressureDiffs*, llvm::LiveIntervals*, bool) ()
#4 0x00000000017d3c89 in llvm::ScheduleDAGMILive::buildDAGWithRegPressure() ()
#5 0x00000000017d3d13 in llvm::ScheduleDAGMILive::schedule() ()
#6 0x00000000017d015e in (anonymous namespace)::MachineSchedulerBase::scheduleRegions(llvm::ScheduleDAGInstrs&, bool) [clone .isra.553] ()
#7 0x00000000017d2c11 in (anonymous namespace)::MachineScheduler::runOnMachineFunction(llvm::MachineFunction&) ()
#8 0x000000000177ca13 in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) ()
#9 0x0000000001a29983 in llvm::FPPassManager::runOnFunction(llvm::Function&) ()
#10 0x0000000001a29a2c in llvm::FPPassManager::runOnModule(llvm::Module&) ()
#11 0x0000000001a2a28f in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()

With these mixed in from time to time:

#0 0x0000000001850825 in llvm::SUnit::ComputeDepth() ()
#1 0x00000000017d22a4 in llvm::GenericScheduler::registerRoots() ()
#2 0x00000000017c9002 in llvm::ScheduleDAGMI::initQueues(llvm::ArrayRef<llvm::SUnit*>, llvm::ArrayRef<llvm::SUnit*>) ()
#3 0x00000000017c9439 in llvm::ScheduleDAGMILive::initQueues(llvm::ArrayRef<llvm::SUnit*>, llvm::ArrayRef<llvm::SUnit*>) ()
#4 0x00000000017d3de3 in llvm::ScheduleDAGMILive::schedule() ()
#5 0x00000000017d015e in (anonymous namespace)::MachineSchedulerBase::scheduleRegions(llvm::ScheduleDAGInstrs&, bool) [clone .isra.553] ()
#6 0x00000000017d2c11 in (anonymous namespace)::MachineScheduler::runOnMachineFunction(llvm::MachineFunction&) ()
#7 0x000000000177ca13 in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) ()
#8 0x0000000001a29983 in llvm::FPPassManager::runOnFunction(llvm::Function&) ()
#9 0x0000000001a29a2c in llvm::FPPassManager::runOnModule(llvm::Module&) ()
#10 0x0000000001a2a28f in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()

Are there any new optimization passes I could try switching off?
I could not find any mention in the release notes of new passes.

Best regards,
Martin

I have encountered very long compile times for three large source files containing generated/unrolled code at -O1.
We are talking about 10+ hours here without completing, so it looks very much like an endless loop.
The processes are using 15, 22 and 27 GB of memory but do not appear to grow further.
This worked fine in the past, so appears to be a regression.

Ouch!

Are there any new optimization passes I could try switching off?
I could not find any mention in the release notes of new passes.

It doesn't seem to be any new passes, but the scheduler. Did this work
in RC1? If so, it'll be a lot easier to identify the cause. If not, a
bisection might help.

cheers,
--renato

This may be a shot in the dark (I don’t even know whether your revision includes the culprit revision), but the symptoms seem similar to:
https://bugs.llvm.org//show_bug.cgi?id=31890

It sounds like PR31890 was introduced with r294186, which is well
after the 4.0 branch (r291814), so that's not what's happening here.

Martin, how long does your file usually take to build? Would it be
possible to use creduce to get to a test case that you can upload to
the bug tracker?