No intended functionality change.

llvm-svn: 202588

llvm-svn: 202587

to the build being C++11.

There is clearly still plenty of simplification than can be done here by
using standard type traits instead of rolling our own in many places.

llvm-svn: 202586

LLVM_HAS_RVALUE_REFERENCES macro.

llvm-svn: 202585

is now always 1, as we're requiring C++11 now!

llvm-svn: 202584

llvm-svn: 202583

the core LLVM libraries.

llvm-svn: 202582

llvm-svn: 202581

libraries. It is now always 1 in LLVM builds.

llvm-svn: 202580

on unconditionally. Continuing to break down the C++98 support,
hopefully without breaking anything.

llvm-svn: 202579

llvm-svn: 202578

llvm-svn: 202577

llvm-svn: 202576

llvm-svn: 202575

on the fact that we now build in C++11 mode with modern compilers. This
should flush out any issues. If the build bots are happy with this, I'll
GC all the code for coping without R-value references.

llvm-svn: 202574

llvm-svn: 202573

llvm-svn: 202572

llvm-svn: 202571

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

llvm-svn: 202570

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.

llvm-svn: 202569

C++11. I'm not sure that this is a good idea, but I know some crazy
folks on the core working group who like to live dangerously, and they
should still be able to build LLD. =D

llvm-svn: 202568

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

llvm-svn: 202567

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.

llvm-svn: 202566

llvm-svn: 202565

llvm-svn: 202564

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

llvm-svn: 202563

When lowering a bitfield, CGRecordLowering would assign the wrong 
storage type to a bitfield in some cases and trigger an assertion.  In 
these cases the layout was still correct, just the bitfield info was 
wrong.

llvm-svn: 202562

<rdar://problem/15949113>

llvm-svn: 202561

it, importers of B should not see the macro. This is complicated by the fact
that A's macro could also be visible through a different path. The rules (as
hashed out on cfe-commits) are included as a documentation update in this
change.

With this, the number of regressions in libc++'s testsuite when modules are
enabled drops from 47 to 7. Those remaining 7 are also macro-related, and are
due to remaining bugs in this change (in particular, the handling of submodules
is imperfect).

llvm-svn: 202560

This documents some of the status of supported functionality in MSVC
quirks mode.  Some of this should be in
http://clang.llvm.org/compatibility.html instead when things have
stabilized.

llvm-svn: 202559

llvm-svn: 202558

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.

llvm-svn: 202557

Patch by Jevin Sweval!

llvm-svn: 202556

llvm-svn: 202555

Reverting until the C++11 switch is complete.

llvm-svn: 202554

Additional conditions that prevent useful nodes before call from being reclaimed.

llvm-svn: 202553

read during materialization.  First of all, report
if we can't read the data for some reason.  Second,
consult the ValueObject's error and report that if
there's some problem.

<rdar://problem/16074201>

llvm-svn: 202552

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.

llvm-svn: 202551

It looks like the contents of the table need to be sorted according to its
value, so that the runtime can find the entry by binary search. I'm not 100%
sure if we really have to do that, but at least I can say it's safe to do
because the contents of .sxdata is just a list of exception handlers' RVAs.

llvm-svn: 202550

This seems a little more straightforward and is equivalent to r201457
for ELF core files.  A case for FreeBSD i386 is also added (it was
incorrectly using the 64-bit register context and corrupting mememory).

Better (user-facing) error handling is still needed.

Review: http://llvm-reviews.chandlerc.com/D2765
llvm-svn: 202549