[llvm-commits] [llvm] r144188 - in /llvm/trunk: lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp test/CodeGen/X86/fold-pcmpeqd-0.ll test/CodeGen/X86/multiple-libcalls-and-twoaddr-deps-scheduling.ll

[Evan Cheng]

r144267 should fix PR11314. Let's see if DragonEgg is happy.

Evan

On Nov 9, 2011, at 10:43 PM, Chandler Carruth wrote:

> On Wed, Nov 9, 2011 at 10:27 PM, Evan Cheng <evan.cheng at apple.com> wrote:
> 
> On Nov 9, 2011, at 5:15 PM, Chandler Carruth wrote:
> 
>> On Wed, Nov 9, 2011 at 6:20 AM, Duncan Sands <baldrick at free.fr> wrote:
>> Author: baldrick
>> Date: Wed Nov  9 08:20:48 2011
>> New Revision: 144188
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=144188&view=rev
>> Log:
>> Speculatively revert commit 144124 (djg) in the hope that the 32 bit
>> dragonegg self-host buildbot will recover (it is complaining about object
>> files differing between different build stages).  Original commit message:
>> 
>> Add a hack to the scheduler to disable pseudo-two-address dependencies in
>> basic blocks containing calls. This works around a problem in which
>> these artificial dependencies can get tied up in calling seqeunce
>> scheduling in a way that makes the graph unschedulable with the current
>> approach of using artificial physical register dependencies for calling
>> sequences. This fixes PR11314.
>> 
>> Evan, I'm told I should ping you, as this leaves us with a crash-on-valid regression checked in. Nick asked Dan to revert the underlying patch, and he said to ask you.
>> 
>> I'm a bit concerned with the situation this leaves the tree in, as we have reverted a fix to a crasher regression in order to fix a stage2/stage3 regression. That doesn't really improve the state of mainline LLVM; if anything it makes it worse.
>> 
>> What's the motivation for keeping r143660 checked in? We're trying to cut a release, and we can't because mainline is broken. We're not the only ones (or a local patch would work well), and generally this violates the spirit of the LLVM mainline: revert until green.
>> 
>> This is particularly strange as Duncan has partially pursued the policy of revert when a patch causes a regression, and justified the revert on that policy, but we're now told we can't *finish* reverting until the regressions are gone...
> 
> My proposal to Dan was rather than reverting r143660 + r144124 to get the buildbots green, keep them in an fix PR11314 in a different way. That is, I've given him the go ahead to disable the scheduler optimization.
> 
> The chain of events is r143660 fixed some very nasty miscompilations. Unfortunately that caused PR11314. r144124 is a workaround for PR11314, which unfortunately caused the DragonEgg self-hosting issue. As far as we can determine reverting r144124 merely paper over some down stream bug. We really need to understand what's the real cause.
> 
> So as you can see, reverting these patches don't really solve any real problem. Disabling the optimization should be as fast as the revert and it will allow everyone to continue to move forward. I'd expect the change should have been done already.
> 
> Ah, thank you for the explanation! Makes the (quite tricky situation) much more clear. Thanks to both you and Dan for working so hard to get everything working! 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20111109/6c56c621/attachment.html>