llvm-svn: 194320

definition. If we see something that looks like a namespace definition inside a
class, that strongly indicates that a close brace was missing somewhere.

llvm-svn: 194319

r-value references. I still want to test that when we have them,
llvm_move is actually a move.

Have I mentioned that I really want to move to C++11? ;]

llvm-svn: 194318

Clang managed to never instantiate the copy constructor. Added tests to
ensure this path is tested.

We could still use tests for the polymorphic nature. Those coming up
next.

llvm-svn: 194317

to fix C++98 builds.

llvm-svn: 194316

unique ownership smart pointer which is *deep* copyable by assuming it
can call a T::clone() method to allocate a copy of the owned data.

This is mostly useful with containers or other collections of uniquely
owned data in C++98 where they *might* copy. With C++11 we can likely
remove this in favor of move-only types and containers wrapped around
those types.

llvm-svn: 194315

llvm-svn: 194314

llvm-svn: 194313

similar commands that duplicate the declaration name)

llvm-svn: 194312

llvm-svn: 194311

This used to interfere with AlwaysBreakBeforeMultilineStrings.

This fixes llvm.org/PR17856.

llvm-svn: 194310

formal arguments on the stack and stores created afterwards. We need this to
ensure tail call optimized function calls do not write over the argument area
of the stack before it is read out.
 

llvm-svn: 194309

llvm-svn: 194308

It is not safe to emit alias to undefined (not supported by ELF or COFF), but
it is safe to rauw when the alias would have been internal or linkonce_odr.

llvm-svn: 194307

This patch moves the jump address materialization inside the noop slide. This
enables patching of the materialization itself or its complete removal. This
patch also adds the ability to define scratch registers that can be used safely
by the code called from the patchpoint intrinsic. At least one scratch register
is required, because that one is used for the materialization of the jump
address. This patch depends on D2009.

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

Reviewed by Andy

llvm-svn: 194306

llvm-svn: 194305

This would cause internal symbols that are only referenced by global initializers to be removed.

This reverts commit 194219.

llvm-svn: 194304

This reverts commit 194219.

llvm-svn: 194303

- removed all gaps from the g/G packets
- optimized registers for x86_64 to not send/receive xmm0-xmm15 as well as ymm0-ymm15, now we only send ymm0-15 and xmm0-15 are now pseudo regs
- Fixed x86_64 floating point register gaps
- Fixed x86_64 so that xmm8-xmm15 don't overlap with ymm0-ymm3. This could lead to bad values showing in the debugger and was due to bad register info structure contents
- Fixed i386 so we only send ymm0-ymm7 and xmm0-xmm7 are now pseudo regs.
- Fixed ARM register definitions to not have any gaps
- Fixed it so value registers and invalidation registers are specified using register names which avoid games we had to play with register numbering in the ARM plugin.

llvm-svn: 194302

llvm-svn: 194301

The new graph structure replaces the node and edge linked lists with vectors.
Free lists (well, free vectors) are used for fast insertion/deletion.

The ultimate aim is to make PBQP graphs cheap to clone. The motivation is that
the PBQP solver destructively consumes input graphs while computing a solution,
forcing the graph to be fully reconstructed for each round of PBQP. This
imposes a high cost on large functions, which often require several rounds of
solving/spilling to find a final register allocation. If we can cheaply clone
the PBQP graph and incrementally update it between rounds then hopefully we can
reduce this cost. Further, once we begin pooling matrix/vector values (future
work), we can cache some PBQP solver metadata and share it between cloned
graphs, allowing the PBQP solver to re-use some of the computation done in
earlier rounds.

For now this is just a data structure update. The allocator and solver still
use the graph the same way as before, fully reconstructing it between each
round. I expect no material change from this update, although it may change
the iteration order of the nodes, causing ties in the solver to break in
different directions, and this could perturb the generated allocations
(hopefully in a completely benign way).

Thanks very much to Arnaud Allard de Grandmaison for encouraging me to get back
to work on this, and for a lot of discussion and many useful PBQP test cases.

llvm-svn: 194300

llvm-svn: 194299

There were 6 on darwin. All of these were related to the recent changes for exec.

llvm-svn: 194298

instead of 'instantiated from:'. The actual wording of the note was
changed in r135135.

llvm-svn: 194297

llvm-svn: 194296

llvm-svn: 194295

Before, existing code in the form of:

  int a; // this is a.
  // This is
  // b.
  int b;

Got turned into:

  int a; // this is a.
         // This is
  // b.
  int b;

llvm-svn: 194294

The idea of the AnyReg Calling Convention is to provide the call arguments in
registers, but not to force them to be placed in a paticular order into a
specified set of registers. Instead it is up tp the register allocator to assign
any register as it sees fit. The same applies to the return value (if
applicable).

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

Reviewed by Andy

llvm-svn: 194293

llvm-svn: 194292

llvm-svn: 194291

llvm-svn: 194290

whether we can safely lower a conditional operator to select was insufficient.
I've left a large comment in place to explaining the sort of problems that this
transform can encounter in clang in the hopes of discouraging others from
reimplementing it wrongly again in the future. (The test should also help with
that, but it's easy to work around any single test I might add and think that
your particular implementation doesn't miscompile any code.)

llvm-svn: 194289

Unlike an alias a rauw is always safe, so we don't need to avoid this
optimization when the replacement is not know to be available in every TU.

llvm-svn: 194288

Sublime Text 2 uses Python 2.6
Sublime Text 3 uses Python 3.3

The `print` function has been available as a __future__ import since
2.6, so use it.

Patch by Johan Engelen!

llvm-svn: 194287

increase the accuracy of register pressure computation in the presence of dead definitions by using live intervals, if available, to identify dead definitions and proceed accordingly.

llvm-svn: 194286

On darwin, when trying to create compact unwind info, a .cfi_cfa_def
directive would case an llvm_unreachable() to be hit. Back off when we
see this directive and generate the regular DWARF style eh_frame.

rdar://15406518

llvm-svn: 194285

llvm-svn: 194284

llvm-svn: 194283

Thanks to Eric Christopher for the tips on the appropriate way to do this.

llvm-svn: 194282

llvm-svn: 194281