[llvm-testresults] buildbot failure in lab.llvm.org on phase2 - living

[llvmlab-buildmaster at lab.llvm.org]

The Buildbot has detected a new failure on builder phase2 - living while building lab.llvm.org.
Full details are available at:
 http://lab.llvm.org:8013/builders/phase2%20-%20living/builds/6866

Buildbot URL: http://lab.llvm.org:8013/

Buildslave for this Build: macpro1

Build Reason: scheduler
Build Source Stamp: 199659
Blamelist: hfinkel

BUILD FAILED: failed

sincerely,
 -The Buildbot


================================================================================

CHANGES:
File: lib/CodeGen/ScheduleDAGInstrs.cpp
On: smooshlab-project
At: Mon 20 Jan 2014 06:10:33
Changed By: hfinkel
Comments: Track multiple stores per object when using AA in ScheduleDAGInstrs

When using AA to break false chain dependencies, we need to track multiple
stores per object in ScheduleDAGInstrs. Historically, we tracked potential alias
chains at the object level, and so all loads of an object would retain
dependencies on any store to that object. With AA, however, this is not
sufficient: non-overlapping stores and loads to the same object all need to be
tested for dependencies separately, we cannot only test all loads to an object
against only the last store (see PR18497 for an explicit example).

To mitigate any unwelcome compile-time impact when not using AA, only one store
is kept in the list per object when not using AA.

This, along with a stack coloring change to come shortly, will provide a test
case, fix PR18497 (and allow LLVM to compile itself using -enable-aa-sched-mi
on x86-64).Properties: 
  phase_id: r199659-t20140120_065632-b15745



Files:
 lib/CodeGen/StackColoring.cpp
 test/CodeGen/X86/misched-aa-colored.ll
 test/CodeGen/X86/pr14090.ll
On: smooshlab-project
At: Mon 20 Jan 2014 06:10:33
Changed By: hfinkel
Comments: Update IR when merging slots in stack coloring

The way that stack coloring updated MMOs when merging stack slots, while
correct, is suboptimal, and is incompatible with the use of AA during
instruction scheduling. The solution, which involves the use of const_cast (and
more importantly, updating the IR from within an MI-level pass), obviously
requires some explanation:

When the stack coloring pass was originally committed, the code in
ScheduleDAGInstrs::buildSchedGraph tracked possible alias sets by using
GetUnderlyingObject, and all load/store and store/store memory control
dependencies where added between SUs at the object level (where only one
object, that returned by GetUnderlyingObject, was used to identify the object
associated with each MMO). When stack coloring merged stack slots, it would
replace MMOs derived from the remapped alloca with the alloca with which the
remapped alloca was being replaced. Because ScheduleDAGInstrs only used single
objects, and tracked alias sets at the object level, this was a fine solution.

In r169744, (Andy and) I updated the code in ScheduleDAGInstrs to use
GetUnderlyingObjects, and track alias sets using, potentially, multiple
underlying objects for each MMO. This was done, primarily, to provide the
ability to look through PHIs, and provide better scheduling for
induction-variable-dependent loads and stores inside loops. At this point, the
MMO-updating code in stack coloring became suboptimal, because it would clear
the MMOs for (i.e. completely pessimize) all instructions for which r169744
might help in scheduling. Updating the IR directly is the simplest fix for this
(and the one with, by far, the least compile-time impact), but others are
possible (we could give each MMO a small vector of potential values, or make
use of a remapping table, constructed from MFI, inside ScheduleDAGInstrs).

Unfortunately, replacing all MMO values derived from the remapped alloca with
the base replacement alloca fundamentally breaks our ability to use AA during
instruction scheduling (which is critical to performance on some targets). The
reason is that the original MMO might have had an offset (either constant or
dynamic) from the base remapped alloca, and that offset is not present in the
updated MMO. One possible way around this would be to use
GetPointerBaseWithConstantOffset, and update not only the MMO's value, but also
its offset based on the original offset. Unfortunately, this solution would
only handle constant offsets, and for safety (because AA is not completely
restricted to deducing relationships with constant offsets), we would need to
clear all MMOs without constant offsets over the entire function. This would be
an even worse pessimization than the current single-object restriction. Any
other solution would involve passing around a vector of remapped allocas, and
teaching AA to use it, introducing additional complexity and overhead into AA.

Instead, when remapping an alloca, we replace all IR uses of that alloca as
well (optionally inserting a bitcast as necessary). This is even more efficient
that the old MMO-updating code in the stack coloring pass (because it removes
the need to call GetUnderlyingObject on all MMO values), removes the
single-object pessimization in the default configuration, and enables the
correct use of AA during instruction scheduling (all without any additional
overhead).

LLVM now no longer miscompiles itself on x86_64 when using -enable-misched
-enable-aa-sched-mi -misched-bottomup=0 -misched-topdown=0 -misched=shuffle!
Fixed PR18497.

Because the alloca replacement is now done at the IR level, unless the MMO
directly refers to the remapped alloca, the change cannot be seen at the MI
level. As a result, there is no good way to fix test/CodeGen/X86/pr14090.ll.Properties: 
  phase_id: r199659-t20140120_065632-b15745



File: test/CodeGen/X86/misched-aa-colored.ll
On: smooshlab-project
At: Mon 20 Jan 2014 06:16:33
Changed By: hfinkel
Comments: Fix misched-aa-colored.ll to require asserts.

-misched=shuffle is NDEBUG only. Maybe we should change that.Properties: 
  phase_id: r199659-t20140120_065632-b15745



LOGS: