Fix RWMutex to be thread-safe when pthread_rwlock is not available

lib/Support/RWMutex.cpp contains an implementation of RWMutex that
uses pthread_rwlock, but when pthread_rwlock is not available (such as
under NaCl, when using newlib), it silently falls back to using the
no-op definition in lib/Support/Unix/RWMutex.inc, which is not
thread-safe.

Fix this case to be thread-safe by using a normal mutex.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202570 91177308-0d34-0410-b5e6-96231b3b80d8

[C++11] Replace autoconf --enable-cxx11 with --enable-cxx1y. The
baseline is now C++11, and we unconditionally add -std=c++11 to the
flags.

This has the dim potential to break some non-GNU-compatible compiler (in
terms of -std flags) using the makefiles, but those makefiles are
littered with GNU-style compile flags so it would be very surprising to
me for it to actually happen in practice. As always, do let me know if
there is a toolchain you're using where this doesn't work, and I'll be
watching the bots.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202569 91177308-0d34-0410-b5e6-96231b3b80d8

[C++11] Switch the CMake option from LLVM_ENABLE_CXX11 (default on) to
LLVM_ENABLE_CXX1Y (default *off*). =D C++98 is dead. Long live C++11.

I don't exactly recommend using C++1y just yet though...

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202567 91177308-0d34-0410-b5e6-96231b3b80d8

[docs] Update the docs to remove my hedging about C++98 vs. C++11. =]
The switch has been thrown. While I'm still watching for any failures or
problems with this, the documentation can go ahead and move forward.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202566 91177308-0d34-0410-b5e6-96231b3b80d8

[Sparc] 80 column rule. No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202565 91177308-0d34-0410-b5e6-96231b3b80d8

[Sparc] Add support for parsing directives in SparcAsmParser.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202564 91177308-0d34-0410-b5e6-96231b3b80d8

[Sparc] Emit 'restore' instead of 'restore %g0, %g0, %g0'. This improves the readability of the generated code.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202563 91177308-0d34-0410-b5e6-96231b3b80d8

SpillPlacement: fix a bug in iterate.

Inside iterate, we scan backwards then scan forwards in a loop. When iteration
is not zero, the last node was just updated so we can skip it. But when
iteration is zero, we can't skip the last node.

For the testing case, fixing this will save a spill and move register copies
from hot path to cold path.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202557 91177308-0d34-0410-b5e6-96231b3b80d8

[CMake] Remove dead C backend option

Patch by Jevin Sweval!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202556 91177308-0d34-0410-b5e6-96231b3b80d8

Reflow isProfitableToMakeFastCC

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202555 91177308-0d34-0410-b5e6-96231b3b80d8

Jumped the gun with r202551 and broke some bots that weren't yet C++11ified.

Reverting until the C++11 switch is complete.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202554 91177308-0d34-0410-b5e6-96231b3b80d8

New PBQP solver, and updates to the PBQP graph.

The previous PBQP solver was very robust but consumed a lot of memory,
performed a lot of redundant computation, and contained some unnecessarily tight
coupling that prevented experimentation with novel solution techniques. This new
solver is an attempt to address these shortcomings.

Important/interesting changes:

1) The domain-independent PBQP solver class, HeuristicSolverImpl, is gone.
It is replaced by a register allocation specific solver, PBQP::RegAlloc::Solver
(see RegAllocSolver.h).

The optimal reduction rules and the backpropagation algorithm have been extracted
into stand-alone functions (see ReductionRules.h), which can be used to build
domain specific PBQP solvers. This provides many more opportunities for
domain-specific knowledge to inform the PBQP solvers' decisions. In theory this
should allow us to generate better solutions. In practice, we can at least test
out ideas now.

As a side benefit, I believe the new solver is more readable than the old one.

2) The solver type is now a template parameter of the PBQP graph.

This allows the graph to notify the solver of any modifications made (e.g. by
domain independent rules) without the overhead of a virtual call. It also allows
the solver to supply policy information to the graph (see below).

3) Significantly reduced memory overhead.

Memory management policy is now an explicit property of the PBQP graph (via
the CostAllocator typedef on the graph's solver template argument). Because PBQP
graphs for register allocation tend to contain many redundant instances of
single values (E.g. the value representing an interference constraint between
GPRs), the new RASolver class uses a uniquing scheme. This massively reduces
memory consumption for large register allocation problems. For example, looking
at the largest interference graph in each of the SPEC2006 benchmarks (the
largest graph will always set the memory consumption high-water mark for PBQP),
the average memory reduction for the PBQP costs was 400x. That's times, not
percent. The highest was 1400x. Yikes. So - this is fixed.

"PBQP: No longer feasting upon every last byte of your RAM".

Minor details:

- Fully C++11'd. Never copy-construct another vector/matrix!

- Cute tricks with cost metadata: Metadata that is derived solely from cost
matrices/vectors is attached directly to the cost instances themselves. That way
if you unique the costs you never have to recompute the metadata. 400x less
memory means 400x less cost metadata (re)computation.

Special thanks to Arnaud de Grandmaison, who has been the source of much
encouragement, and of many very useful test cases.

This new solver forms the basis for future work, of which there's plenty to do.
I will be adding TODO notes shortly.

- Lang.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202551 91177308-0d34-0410-b5e6-96231b3b80d8

[docs] Clarify that there isn't much to be done other than watch build
bots when using the standard library facilities. The missing pieces here
aren't always in useful discreet chunks.

Fortunately, the missing pieces are few and far between, and we can
emulate most of them in our headers as needed.

Based on feedback from Lang and Dave.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202548 91177308-0d34-0410-b5e6-96231b3b80d8

[C++11] Switch autoconf and make to use C++11 by default. Now both build
systems have the default as C++11, but retain the ability to build with
C++98.

Again, please restrain your enthusiasm a bit in case this needs to be
reverted. =]

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202546 91177308-0d34-0410-b5e6-96231b3b80d8

Fix >> to be > > for non-c++11.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202545 91177308-0d34-0410-b5e6-96231b3b80d8

R600: Verify all instructions in the AsmPrinter on debug builds

Make a call to R600's implementation of verifyInstruction() to
check that instructions are only using legal operands.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202544 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Expand all v16[if]32 operations

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202543 91177308-0d34-0410-b5e6-96231b3b80d8

[C++11] Switch CMake to use C++11 by default! Next up, autoconf/make!

Now, please don't get too excited. I've just toggled the default to suss
out the last remaining bot problems. This does *not* mean we can all go
write lots of C++11 code yet. I at least want to let the dust settle
from the bots first.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202542 91177308-0d34-0410-b5e6-96231b3b80d8

80-col.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202541 91177308-0d34-0410-b5e6-96231b3b80d8

Fix a crasher where when we're attempting to replace a type
during the finalization for CGDebugInfo in clang we would RAUW
a type and it would result in a corrupted MDNode for an
imported declaration.

Testcase pending as reducing has been difficult.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202540 91177308-0d34-0410-b5e6-96231b3b80d8

Add more whitespace to fix more bullets.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202538 91177308-0d34-0410-b5e6-96231b3b80d8

Add whitespace to try to fix bulleted list.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202537 91177308-0d34-0410-b5e6-96231b3b80d8

Fix some links to C++11 feature papers in the Coding Standards

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202532 91177308-0d34-0410-b5e6-96231b3b80d8

add missing 3.4 release

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202531 91177308-0d34-0410-b5e6-96231b3b80d8

CommandLine: Exit successfully for -version and -help

Tools that use the CommandLine library currently exit with an error
when invoked with -version or -help. This is unusual and non-standard,
so we'll fix them to exit successfully instead.

I don't expect that anyone relies on the current behaviour, so this
should be a fairly safe change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202530 91177308-0d34-0410-b5e6-96231b3b80d8

Test commit

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202528 91177308-0d34-0410-b5e6-96231b3b80d8

Fixed operand of SC microMIPS instruction.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202526 91177308-0d34-0410-b5e6-96231b3b80d8

Drop libtool from llvm.

We were only using it so find the shared library extension and nm. There are
simpler ways to do those things :-)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202524 91177308-0d34-0410-b5e6-96231b3b80d8

Fixed encoding of SYSCALL microMIPS instruction.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202523 91177308-0d34-0410-b5e6-96231b3b80d8

Revert revision 202518  because of wrong commit message.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202521 91177308-0d34-0410-b5e6-96231b3b80d8

Fix operand of SC instruction.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202518 91177308-0d34-0410-b5e6-96231b3b80d8

With rpaths being set correctly, SHLIBPATH_VAR is not needed anymore.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202510 91177308-0d34-0410-b5e6-96231b3b80d8

Correctly set rpath for unittests.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202509 91177308-0d34-0410-b5e6-96231b3b80d8

Centralize the handling of install_name and rpath.

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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202499 91177308-0d34-0410-b5e6-96231b3b80d8

[docs] Add a section to the coding standards about languages and such.

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. =]

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202497 91177308-0d34-0410-b5e6-96231b3b80d8

X86Operand is extracted into individual header.

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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202496 91177308-0d34-0410-b5e6-96231b3b80d8

[docs] A slight tweak to the intro for the golden rule in the coding
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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202495 91177308-0d34-0410-b5e6-96231b3b80d8

[docs] Tweak the example to match what is apparantly the desired form
for the style templates we're using.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202494 91177308-0d34-0410-b5e6-96231b3b80d8

[docs] Switch to external hyperlink references. Much more readable and
hopefully easier to get the formatting right for ReST.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202493 91177308-0d34-0410-b5e6-96231b3b80d8

[docs] Fix my links to use the correct ReST syntax.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202490 91177308-0d34-0410-b5e6-96231b3b80d8

[docs] Fix 80-column wrap that I messed up.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202489 91177308-0d34-0410-b5e6-96231b3b80d8

[docs] Tweak discussion of BSDs based on feedback from Roman Divacky.
FreeBSD 10.0 and newer have a modern Clang toolchain that should work
well.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202488 91177308-0d34-0410-b5e6-96231b3b80d8

[docs] Add a big section with details about how to go about acquiring
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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202486 91177308-0d34-0410-b5e6-96231b3b80d8

Reorder Mips/MCTargetDesc/CMakeLists.txt.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202483 91177308-0d34-0410-b5e6-96231b3b80d8

[mips] Add MipsNaClELFStreamer.cpp to CMakeLists.txt.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202482 91177308-0d34-0410-b5e6-96231b3b80d8

[mips] Implement NaCl sandboxing of indirect jumps:

  * 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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202479 91177308-0d34-0410-b5e6-96231b3b80d8

Add 'remark' diagnostic type in LLVM

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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202474 91177308-0d34-0410-b5e6-96231b3b80d8

Turn static inline functions to inline, following Rafael's suggestion

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202473 91177308-0d34-0410-b5e6-96231b3b80d8

Swap PPC isel operands to allow for 0-folding

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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202469 91177308-0d34-0410-b5e6-96231b3b80d8

llvm-objdump: Fix crash bug with printing unwind info on stripped file.

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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202466 91177308-0d34-0410-b5e6-96231b3b80d8

Style fix.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202465 91177308-0d34-0410-b5e6-96231b3b80d8

Now that it is possible, use the mangler in IRObjectFile.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202463 91177308-0d34-0410-b5e6-96231b3b80d8

Rename coff_pdata_x64 -> coff_runtime_function_x64.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202460 91177308-0d34-0410-b5e6-96231b3b80d8

Trying to unbreak the darwin11 builder

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)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202459 91177308-0d34-0410-b5e6-96231b3b80d8

Try to unbreak the C++11 build

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202455 91177308-0d34-0410-b5e6-96231b3b80d8

[CMake] llvm_add_library(SHARED|STATIC): Fix broken OUTPUT_NAME for *_static.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202454 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202451 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202450 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202449 91177308-0d34-0410-b5e6-96231b3b80d8

Remove unnecessary temporary variable.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202445 91177308-0d34-0410-b5e6-96231b3b80d8

Object/COFF: Add a struct for the function table in .pdata.

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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202438 91177308-0d34-0410-b5e6-96231b3b80d8

Provide a target override for the latest regalloc heuristic.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202433 91177308-0d34-0410-b5e6-96231b3b80d8

Drive-by comment fix. This regalloc comment was not accurate.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202432 91177308-0d34-0410-b5e6-96231b3b80d8

[docs] Stop advertising 'make update'. It isn't implemented in CMake and
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".

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202430 91177308-0d34-0410-b5e6-96231b3b80d8

Lower FNEG just like FABS to fneg[ds] and fmov[ds], thus avoiding
expensive libcall. Also, Qp_neg is not implemented on at least
FreeBSD. This is also what gcc is doing.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202422 91177308-0d34-0410-b5e6-96231b3b80d8

Add getter method to access Reloc::Model.

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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202418 91177308-0d34-0410-b5e6-96231b3b80d8

Revert r201751 and solve the const problem a different way - by
making the cache mutable.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202417 91177308-0d34-0410-b5e6-96231b3b80d8

Debug info: Remove ARMAsmPrinter::EmitDwarfRegOp(). AsmPrinter can now
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.)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202416 91177308-0d34-0410-b5e6-96231b3b80d8

[XCore] Support functions returning more than 4 words.

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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202414 91177308-0d34-0410-b5e6-96231b3b80d8

[XCore] Make LowerCallResult a static function.

No functionality change. This is r202396 reapplied with no changes.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202413 91177308-0d34-0410-b5e6-96231b3b80d8

Remove MCPureStreamer.

We moved MCJIT to use native object formats a long time ago and R600
now uses ELF, so it was dead.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202408 91177308-0d34-0410-b5e6-96231b3b80d8

Re-apply r200853, which should not crash after Clang plugins were converted to loadable modules in r201256.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202404 91177308-0d34-0410-b5e6-96231b3b80d8

Revert r202396, r202397.

These are causing test failures, revert for now.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202398 91177308-0d34-0410-b5e6-96231b3b80d8

[XCore] Support functions returning more than 4 words.

Summary:
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.

Reviewers: robertlytton

Reviewed By: robertlytton

CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2889

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202397 91177308-0d34-0410-b5e6-96231b3b80d8

[XCore] Make LowerCallResult a static function.

No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202396 91177308-0d34-0410-b5e6-96231b3b80d8

[XCore] Target optimized library function __memcpy_4()

Summary:
If the src, dst and size of a memcpy are known to be 4 byte aligned we
can call __memcpy_4() instead of memcpy().

Reviewers: robertlytton

Reviewed By: robertlytton

CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2871

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202395 91177308-0d34-0410-b5e6-96231b3b80d8

[XCore] Add dag combines for instructions that ignore some input bits.

These instructions ignore the high bits of one of their input operands -
try and use this to simplify the code.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202394 91177308-0d34-0410-b5e6-96231b3b80d8

[XCore] Provide information about known zero bits of resource instructions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202393 91177308-0d34-0410-b5e6-96231b3b80d8

[asan] fix a pair of silly typos

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202391 91177308-0d34-0410-b5e6-96231b3b80d8

[asan] disable asan-detect-invalid-pointer-pair (was enabled by mistake)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202390 91177308-0d34-0410-b5e6-96231b3b80d8

[asan] *experimental* implementation of invalid-pointer-pair detector (finds when two unrelated pointers are compared or subtracted). This implementation has both false positives and false negatives and is not tuned for performance. A bug report for a proper implementation will follow.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202389 91177308-0d34-0410-b5e6-96231b3b80d8

[docs] Actually spell out the new version requirements for the host C++
toolchain of LLVM. These are already being enforced by the build system
and have been discussed quite a few times on the lists, but
documentation is important. =]

Also, garbage collect the majority of the information about broken host
GCC toolchains. These aren't really relevant any more as they're all
older than the minimum requirement. I've left a few notes about
compilers one step older than the current requirement as these compilers
are at least conceivable to use, and it's better to preserve this kind
of hard-won institutional knowledge.

The next step will be some specific docs on how to set up a sufficiently
modern host toolchain if your system doesn't come with one. But that'll
be tomorrow. =]

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202375 91177308-0d34-0410-b5e6-96231b3b80d8

[docs] Clean up some of the required software to not mention irrelevant
bits of software and to use a modern GCC version.

The Subversion bit was weird anyways -- it has nothing to do with
compiling LLVM. Also, there are many other ways to get at the trunk
source (git, git-svn, etc).

The TeXinfo thing... I have no idea about. But you can get a working
LLVM w/o it pretty easily. If man pages or something are missing, that
hardly seems like a problem. If folks really want this back, let me
know, but it seems mostly like a distraction.

I'd still like to separate this into:
- Required software to compile.
- Optional software to compile.
- Required software for certain *contributor* activities (like
  regenerating configure scripts).

Also we need to mention that there are multiple options for build
systems, and the differences.

Also we should mention Windows.

Also probably other stuff I'm forgetting.

I'm wondering if this whole thing needs to be shot in the head and we
should just start a new, simpler getting started that doesn't have so
many years of accumulated stuff that is no longer relevant.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202373 91177308-0d34-0410-b5e6-96231b3b80d8

[docs] Switch this table to the simple form as well. No content changed.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202372 91177308-0d34-0410-b5e6-96231b3b80d8

[docs] Switch to the incredibly simpler "simple table" form. It now
actually looks like the table on the webpage and is entertainingly
smaller, easier to read, and easier to edit.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202371 91177308-0d34-0410-b5e6-96231b3b80d8

[docs] Delete tons of bad information in the requirements section of the
getting started guide.

Some highlights:
- I heard there was this Clang compiler that you could use for your
  host compiler. Not sure though.
- We no longer have a GCC frontend with weird build restrictions.
- Windows is doing a bit better than partially supported.
- We nuked everything to do with itanium.
- SPUs? Really?
- Xcode 2.5 and gcc 4.0.1 are really not a concern -- they don't work.
- OMG, we actually tried building LLVM on Alpha? Really?
- PowerPC works pretty well these days.

There is still a lot of stuff here I'm pretty dubious about, but I nuked
most of what was actively misleading, out of date, or patently wrong.
Some of it (mingw stuff especially) isn't really lacking, its just that
the comments here were actively wrong. Hopefully folks that know those
platforms can add back correct / modern information.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202370 91177308-0d34-0410-b5e6-96231b3b80d8

Stop test/CodeGen/X86/v4i32load-crash.ll targeting non-X86-64 targets.

Summary:
Fixes an issue where a test attempts to use -mcpu=x86-64 on non-X86-64 targets.
This triggers an assertion in the MIPS backend since it doesn't know what ABI to
use by default for unrecognized processors.

CC: llvm-commits, rafael
Differential Revision: http://llvm-reviews.chandlerc.com/D2877

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202369 91177308-0d34-0410-b5e6-96231b3b80d8

[CMake] Introduce LLVM_BUILD_EXTERNAL_COMPILER_RT option

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202363 91177308-0d34-0410-b5e6-96231b3b80d8

Don't emit anything into the debug_ranges section if we aren't emitting
any ranges - this includes CU ranges where we were previously emitting an
end list marker even if we didn't have a list.

Testcase includes a test for line table only code emission as the problem
was noticed while writing this test.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202357 91177308-0d34-0410-b5e6-96231b3b80d8

Exception handling docs: Fix a typo

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202354 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Fix Uses/Defs lists for INS, OUTS, SCAS, CMPS, LODS

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202348 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Add RAX/EAX/AX Uses/Defs to XCHG RAX/EAX/AX instructions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202347 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Add RAX/EAX/AX/AL Uses/Defs to the absolute memory location move instructions. Patch by Florian Lukas with some additional instructions fixed by me. Fixes PR18975.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202345 91177308-0d34-0410-b5e6-96231b3b80d8

Fix indentation.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202344 91177308-0d34-0410-b5e6-96231b3b80d8

Fix odd indentation.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202342 91177308-0d34-0410-b5e6-96231b3b80d8

Revert "Use count 0."

This reverts commit r202283, because when we use GuardMalloc the test will fail
due to additional output to std err.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202341 91177308-0d34-0410-b5e6-96231b3b80d8

Revert "Use StringRef in raw_fd_ostream constructor"

This reverts commit r202225, which may cause a performance regression.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202338 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Optimize SI_KILL for constant operands

If the SI_KILL operand is constant, we can either clear the exec mask if
the operand is negative, or do nothing otherwise.

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202337 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Allow SI_KILL for geometry shaders

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202336 91177308-0d34-0410-b5e6-96231b3b80d8

If we're only emitting line tables for a particular CU then don't add
any ranges to the list of ranges for the CU as we don't want to emit
them anyway. This ensures that we will still emit ranges if we have
a compile unit compiled with only line tables and one compiled with
full debug info requested (we'll emit for the one with full debug info).

Update testcase metadata accordingly to continue emitting ranges.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202333 91177308-0d34-0410-b5e6-96231b3b80d8