[llvm-testresults] buildbot failure in lab.llvm.org on phase1 - sanity

Thu Feb 27 17:06:17 PST 2014

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

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

Buildslave for this Build: macpro1

Build Reason: scheduler
Build Source Stamp: 202454
Blamelist: alexfh,chapuni,hfinkel

BUILD FAILED: failed

sincerely,
 -The Buildbot

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

CHANGES:
File: lib/CodeGen/SelectionDAG/DAGCombiner.cpp
On: http://10.1.1.2/svn/llvm-project
For: llvm
At: Thu 27 Feb 2014 16:36:16
Changed By: hfinkel
Comments: Fix visitTRUNCATE for legal i1 values

This extract-and-trunc vector optimization cannot work for i1 values as
currently implemented, and so I'm disabling this for now for i1 values. In the
future, this can be fixed properly.

Soon I'll commit support for i1 CR bit tracking in the PowerPC backend, and
this will be covered by one of the existing regression tests.Properties: 

Files:
 include/llvm/Target/TargetSelectionDAG.td
 utils/TableGen/CodeGenDAGPatterns.cpp
 utils/TableGen/CodeGenDAGPatterns.h
On: http://10.1.1.2/svn/llvm-project
For: llvm
At: Thu 27 Feb 2014 16:36:16
Changed By: hfinkel
Comments: Add an OutPatFrag TableGen class

Unfortunately, it is currently impossible to use a PatFrag as part of an output
pattern (the part of the pattern that has instructions in it) in TableGen.
Looking at the current implementation, this was clearly intended to work (there
is already code in place to expand patterns in the output DAG), but is
currently broken by the baked-in type-checking assumption and the order in which
the pattern fragments are processed (output pattern fragments need to be
processed after the instruction definitions are processed).

Fixing this is fairly simple, but requires some way of differentiating output
patterns from the existing input patterns. The simplest way to handle this
seems to be to create a subclass of PatFrag, and so that's what I've done here.

As a simple example, this allows us to write:

def crnot : OutPatFrag<(ops node:$in),
                       (CRNOR $in, $in)>;

def       : Pat<(not i1:$in),
                (crnot $in)>;

which captures the core use case: handling of repeated subexpressions inside
of complicated output patterns.

This will be used by an upcoming commit to the PowerPC backend.Properties: 

Files:
 lib/Target/PowerPC/InstPrinter/PPCInstPrinter.cpp
 lib/Target/PowerPC/MCTargetDesc/PPCPredicates.cpp
 lib/Target/PowerPC/MCTargetDesc/PPCPredicates.h
 lib/Target/PowerPC/PPC.td
 lib/Target/PowerPC/PPCBranchSelector.cpp
 lib/Target/PowerPC/PPCCallingConv.td
 lib/Target/PowerPC/PPCFastISel.cpp
 lib/Target/PowerPC/PPCISelDAGToDAG.cpp
 lib/Target/PowerPC/PPCISelLowering.cpp
 lib/Target/PowerPC/PPCISelLowering.h
 lib/Target/PowerPC/PPCInstr64Bit.td
 lib/Target/PowerPC/PPCInstrFormats.td
 lib/Target/PowerPC/PPCInstrInfo.cpp
 lib/Target/PowerPC/PPCInstrInfo.td
 lib/Target/PowerPC/PPCRegisterInfo.cpp
 lib/Target/PowerPC/PPCRegisterInfo.h
 lib/Target/PowerPC/PPCRegisterInfo.td
 lib/Target/PowerPC/PPCSubtarget.cpp
 lib/Target/PowerPC/PPCSubtarget.h
 lib/Target/PowerPC/PPCTargetMachine.cpp
 test/CodeGen/PowerPC/bdzlr.ll
 test/CodeGen/PowerPC/crbits.ll
 test/CodeGen/PowerPC/early-ret2.ll
 test/CodeGen/PowerPC/fold-zero.ll
 test/CodeGen/PowerPC/optcmp.ll
 test/CodeGen/PowerPC/rlwimi-and.ll
 test/CodeGen/PowerPC/sdag-ppcf128.ll
 test/CodeGen/PowerPC/setcc_no_zext.ll
 test/CodeGen/PowerPC/seteq-0.ll
 test/CodeGen/PowerPC/subsumes-pred-regs.ll
On: http://10.1.1.2/svn/llvm-project
For: llvm
At: Thu 27 Feb 2014 16:36:16
Changed By: hfinkel
Comments: Add CR-bit tracking to the PowerPC backend for i1 values

This change enables tracking i1 values in the PowerPC backend using the
condition register bits. These bits can be treated on PowerPC as separate
registers; individual bit operations (and, or, xor, etc.) are supported.
Tracking booleans in CR bits has several advantages:

 - Reduction in register pressure (because we no longer need GPRs to store
   boolean values).

 - Logical operations on booleans can be handled more efficiently; we used to
   have to move all results from comparisons into GPRs, perform promoted
   logical operations in GPRs, and then move the result back into condition
   register bits to be used by conditional branches. This can be very
   inefficient, because the throughput of these CR <-> GPR moves have high
   latency and low throughput (especially when other associated instructions
   are accounted for).

 - On the POWER7 and similar cores, we can increase total throughput by using
   the CR bits. CR bit operations have a dedicated functional unit.

Most of this is more-or-less mechanical: Adjustments were needed in the
calling-convention code, support was added for spilling/restoring individual
condition-register bits, and conditional branch instruction definitions taking
specific CR bits were added (plus patterns and code for generating bit-level
operations).

This is enabled by default when running at -O2 and higher. For -O0 and -O1,
where the ability to debug is more important, this feature is disabled by
default. Individual CR bits do not have assigned DWARF register numbers,
and storing values in CR bits makes them invisible to the debugger.

It is critical, however, that we don't move i1 values that have been promoted
to larger values (such as those passed as function arguments) into bit
registers only to quickly turn around and move the values back into GPRs (such
as happens when values are returned by functions). A pair of target-specific
DAG combines are added to remove the trunc/extends in:
  trunc(binary-ops(binary-ops(zext(x), zext(y)), ...)
and:
  zext(binary-ops(binary-ops(trunc(x), trunc(y)), ...)
In short, we only want to use CR bits where some of the i1 values come from
comparisons or are used by conditional branches or selects. To put it another
way, if we can do the entire i1 computation in GPRs, then we probably should
(on the POWER7, the GPR-operation throughput is higher, and for all cores, the
CR <-> GPR moves are expensive).

POWER7 test-suite performance results (from 10 runs in each configuration):

SingleSource/Benchmarks/Misc/mandel-2: 35% speedup
MultiSource/Benchmarks/Prolangs-C++/city/city: 21% speedup
MultiSource/Benchmarks/MiBench/automotive-susan: 23% speedup
SingleSource/Benchmarks/CoyoteBench/huffbench: 13% speedup
SingleSource/Benchmarks/Misc-C++/Large/sphereflake: 13% speedup
SingleSource/Benchmarks/Misc-C++/mandel-text: 10% speedup

SingleSource/Benchmarks/Misc-C++-EH/spirit: 10% slowdown
MultiSource/Applications/lemon/lemon: 8% slowdownProperties: 

Files:
 clang-tidy/ClangTidyDiagnosticConsumer.cpp
 test/clang-tidy/nolint.cpp
On: http://10.1.1.2/svn/llvm-project
For: clang-tools-extra
At: Thu 27 Feb 2014 16:36:16
Changed By: alexfh
Comments: Added a naive NOLINT implementation.

Summary:
Added a naive NOLINT implementation. It doesn't care about specific
linter categories, just the "// NOLINT" on the same line as a diagnostic.

Reviewers: klimek

Reviewed By: klimek

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2896Properties: 

Files:
 include/clang/Driver/Options.td
 test/Driver/ppc-features.cpp
On: http://10.1.1.2/svn/llvm-project
For: cfe
At: Thu 27 Feb 2014 16:36:17
Changed By: hfinkel
Comments: Add -mcrbits/-mno-crbits to control the PowerPC CR-bit-tracking feature

The backend currently enables CR-bit tracking by default at -O2 and higher.
These flags allow the user to override that default.Properties: 

File: cmake/modules/AddLLVM.cmake
On: http://10.1.1.2/svn/llvm-project
For: llvm
At: Thu 27 Feb 2014 16:36:17
Changed By: chapuni
Comments: [CMake] llvm_add_library(SHARED|STATIC): Fix broken OUTPUT_NAME for *_static.Properties: 

LOGS: