llvm-svn: 202521

llvm-svn: 202518

llvm-svn: 202510

This lets us run the unittest from the command line without setting
LD_LIBRARY_PATH.

llvm-svn: 202509

This centralizes the Makefile handling of -install_name and -rpath. It also
moves the cmake build to using @rpath. The reason being that libclang needs it,
and it works for everything else.

A followup patch will move clang to using this and then there will be a single
point to edit to support other systems.

llvm-svn: 202499

A lot of this is writing down common knowledge and things often
communicated on mailing lists and in discussions. It could live in the
Programmer's Manual alternatively, but that felt slightly less
well-fitting.

It also includes (and was motivated by) the section on the relevant
language standards for LLVM and the specific features that will be
enabled with the switch to C++11.

With this, all of the documentation for the C++11 switch is, I think, in
place. I plan to flip the switch RSN. =]

llvm-svn: 202497

X86Operand is extracted into individual header, because it allows to create an
arbitrary memory operand and append it to MCInst. It'll be reused in X86 inline
assembly instrumentation.

Patch by Yuri Gorshenin.

llvm-svn: 202496

standards.

It claims the document intentionally doesn't give fixed standards for
brace placement or spacing, and then the document goes on to do
precisely that in several places. Instead, try to highlight that even
these rules are simply *guidance* which may be trumped by some other
circumstance or the local conventions of code.

I'm not trying to change the thrust of this part of the document, and if
folks think this does so, I'm happy to re-wordsmith it. I just don't
want it to be so self-contradicting.

llvm-svn: 202495

for the style templates we're using.

llvm-svn: 202494

hopefully easier to get the formatting right for ReST.

llvm-svn: 202493

llvm-svn: 202490

llvm-svn: 202489

FreeBSD 10.0 and newer have a modern Clang toolchain that should work
well.

llvm-svn: 202488

a more modern host C++ toolchain for Linux distros where folks sometimes
don't have a good option to get one as part of their system.

This is a first cut, so feedback, testing, and suggestions are very,
very welcom. This is one of the last real documentation changes that was
specifically requested prior to switching LLVM and Clang to build in
C++11 mode by default.

llvm-svn: 202486

llvm-svn: 202483

llvm-svn: 202482

  * Align targets of indirect jumps to instruction bundle boundaries (in MI layer).
  * Add masking instructions before indirect jumps (in MC layer).

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

llvm-svn: 202479

A 'remark' is information that is not an error or a warning, but rather some
additional information provided to the user. In contrast to a 'note' a 'remark'
is an independent diagnostic, whereas a 'note' always depends on another
diagnostic.

A typical use case for remark nodes is information provided to the user, e.g.
information provided by the vectorizer about loops that have been vectorized.

llvm-svn: 202474

llvm-svn: 202473

The PPC isel instruction can fold 0 into the first operand (thus eliminating
the need to materialize a zero-containing register when the 'true' result of
the isel is 0). When the isel is fed by a bit register operation that we can
invert, do so as part of the bit-register-operation peephole routine.

llvm-svn: 202469

The current COFF unwind printer tries to print SEH handler function names,
assuming that it can always find function names in string table. It crashes
if file being read has no symbol table (i.e. executable).

With this patch, llvm-objdump prints SEH handler's RVA if there's no symbol
table entry for that RVA.

llvm-svn: 202466

llvm-svn: 202465

A really simple patch marks the end of a lot of yak shaving :-)

llvm-svn: 202463

llvm-svn: 202460

The CR bit tracking code broke PPC/Darwin; trying to get it working again...

(the darwin11 builder, which defaults to the darwin ABI when running PPC tests,
asserted when running test/CodeGen/PowerPC/inverted-bool-compares.ll)

llvm-svn: 202459

Cannot use negative numbers in case statements without running afoul of -Wc++11-narrowing.

llvm-svn: 202455

llvm-svn: 202454

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% slowdown

llvm-svn: 202451

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.

llvm-svn: 202450

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.

llvm-svn: 202449

llvm-svn: 202445

This is the data structure listed on Microsoft PE/COFF Spec Revision 8.3, p. 80.
The name of the struct is not mentioned in the Microsoft PE/COFF spec, so I made
it up.

llvm-svn: 202438

This is a temporary workaround for native arm linux builds:
PR18996: Changing regalloc order breaks "lencod" on native arm linux builds.

llvm-svn: 202433

llvm-svn: 202432

seems unlikely to be added. It also doesn't seem like it should be part
of the build system at all (consider out-of-tree builds).

We should probably add nice, easy tool for this that works both for svn
client trees and git-svn client trees, but it probably won't be spelled
"make update".

llvm-svn: 202430

expensive libcall. Also, Qp_neg is not implemented on at least
FreeBSD. This is also what gcc is doing.

llvm-svn: 202422

Some MC components like Target Streamers or Assembly Parsers
may need to access the relocation model in order to expand
some directives and/or assembly macros.

llvm-svn: 202418

making the cache mutable.

llvm-svn: 202417

scan the register file for sub- and super-registers.
No functionality change intended.

(Tests are updated because the comments in the assembler output are
different.)

llvm-svn: 202416

If a function returns a large struct by value return the first 4 words
in registers and the rest on the stack in a location reserved by the
caller. This is needed to support the xC language which supports
functions returning an arbitrary number of return values. This is
r202397 reapplied with a fix to avoid an uninitialized read of a member.

llvm-svn: 202414