[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 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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20111109/53815709/attachment.html>