[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

[Chandler Carruth]

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/32c1ebc6/attachment.html>