llvm-svn: 99544

 - Still O(N^2), just a faster form, and now its the MCAsmLayout's fault.

On the .s I am tuning against (combine.s from 403.gcc):
--
ddunbar@lordcrumb:MC$ diff stats-before.txt stats-after.txt
5,10c5,10
<    1728 assembler - Number of assembler layout and relaxation steps
<    7707 assembler - Number of emitted assembler fragments
<  120588 assembler - Number of emitted object file bytes
< 2233448 assembler - Number of evaluated fixups
<    1727 assembler - Number of relaxed instructions
< 6723845 mcexpr    - Number of MCExpr evaluations
---
>      3 assembler - Number of assembler layout and relaxation steps
>   7707 assembler - Number of emitted assembler fragments
> 120588 assembler - Number of emitted object file bytes
>  14796 assembler - Number of evaluated fixups
>   1727 assembler - Number of relaxed instructions
>  67889 mcexpr    - Number of MCExpr evaluations
--
Feel free to LOL at the -before numbers, if you like.

I am a little surprised we make more than 2 relaxation passes. It's pretty
trivial for us to do relaxation out-of-order if that would give a speedup.

llvm-svn: 99543

llvm-svn: 99542

llvm-svn: 99540

Remove much horribleness from X86InstrFormats as a result. Similar
simplifications are probably possible for other targets.

llvm-svn: 99539

the custom insertion hook deletes the instruction, then we try to set dead
flags on it.  Neither the code that I added nor the code that was there 
before was safe.

llvm-svn: 99538

llvm-svn: 99537

llvm-svn: 99529

llvm-svn: 99528

llvm-svn: 99526

llvm-svn: 99525

On Nehalem and newer CPUs there is a 2 cycle latency penalty on using a register
in a different domain than where it was defined. Some instructions have
equvivalents for different domains, like por/orps/orpd.

The SSEDomainFix pass tries to minimize the number of domain crossings by
changing between equvivalent opcodes where possible.

This is a work in progress, in particular the pass doesn't do anything yet. SSE
instructions are tagged with their execution domain in TableGen using the last
two bits of TSFlags. Note that not all instructions are tagged correctly. Life
just isn't that simple.

The SSE execution domain issue is very similar to the ARM NEON/VFP pipeline
issue handled by NEONMoveFixPass. This pass may become target independent to
handle both.

llvm-svn: 99524

gcc, and the common expectation seems to be that they are unused. If and when
someone cares we can add them back with well documented demantics.

llvm-svn: 99522

instead of the current N2V.  Format of NVDupLane instances are set to NEONFrm
currently.

llvm-svn: 99518

llvm-svn: 99516

llvm-svn: 99515

opcode values fitting in one byte (svn r99494).

llvm-svn: 99514

llvm-svn: 99513

llvm-svn: 99512

llvm-svn: 99510

  - When substituting template arguments as part of template argument
    deduction, introduce a new local instantiation scope.
  - When substituting into a function prototype type, introduce a new
    "temporary" local instantiation scope that merges with its outer
    scope but also keeps track of any additions it makes, removing
    them when we exit that scope.

Fixes PR6700, where we were getting too much mixing of local
instantiation scopes due to template argument deduction that
substituted results into function types.

llvm-svn: 99509

When -fdump-vtable-layouts is specified, construction vtable initializers will be generated using the new vtable layout code. (The code is still not completely in place but this is a huge step forward).

llvm-svn: 99508

llvm-svn: 99507

now configures prerequisite projects individually but also ignores them in the
big project switch statement to avoid the incorrect warning.

llvm-svn: 99506

llvm-svn: 99505

llvm-svn: 99504

Scheduler assumes SDDbgValue nodes are in source order. That's true currently. But add an assertion to verify it.

llvm-svn: 99501

llvm-svn: 99500

llvm-svn: 99499

use with Python's unittest.

llvm-svn: 99498

the redeclaration chain.  Recommitted from r99477 with a fix:  we need to
merge in default template arguments from previous declarations.

llvm-svn: 99496

llvm-svn: 99495

bytes instead of one byte.  This is important because
we're running up to too many opcodes to fit in a byte
and it is aggrevated by FIRST_TARGET_MEMORY_OPCODE
making the numbering sparse.  This just bites the
bullet and bloats out the table.  In practice, this
increases the size of the x86 isel table from 74.5K
to 76K.  I think we'll cope :)

This fixes rdar://7791648

llvm-svn: 99494

llvm-svn: 99493

If a TableGen class has an initializer expression containing an X.Y subexpression,
AND X depends on template parameters,
AND those template parameters have defaults,
AND some parameters with defaults are beyond position 1,
THEN parts of the initializer expression are evaluated prematurely with the default values when the first explicit template parameter is substituted, before the remaining explicit template parameters have been substituted.

llvm-svn: 99492

llvm-svn: 99490

llvm-svn: 99489

llvm-svn: 99488

llvm-svn: 99487

handles dead implicit results more aggressively.  More
to come, I think this is now just a data entry problem.

llvm-svn: 99486