llvm-svn: 99567

It doesn't seem to be used anywhere.

llvm-svn: 99566

llvm-svn: 99565

llvm-svn: 99564

exactly two passes in that case, and don't ever need to recompute any layout,
so this is a nice baseline for relaxation performance.

llvm-svn: 99563

llvm-svn: 99557

llvm-svn: 99549

expect a Format arg.  N2VCvtD/N2VCvtQ are modified to use the NVCVTFrm format.

llvm-svn: 99548

llvm-svn: 99546

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

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

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

llvm-svn: 99518

opcode values fitting in one byte (svn r99494).

llvm-svn: 99514

llvm-svn: 99512

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

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

happening.

Enhance scheduling to set the DEAD flag on implicit defs
more aggressively.  Before, we'd set an implicit def operand
to dead if it were present in the SDNode corresponding to
the machineinstr but had no use.  Now we do it in this case
AND if the implicit def does not exist in the SDNode at all.

This exposes a couple of problems: one is the FIXME, which
causes a live intervals crash on CodeGen/X86/sibcall.ll.
The second is that it makes machinecse and licm more 
aggressive (which is a good thing) but also exposes a case
where licm hoists a set0 and then it doesn't get resunk.

Talking to codegen folks about both these issues, but I need
this patch in in the meantime.

llvm-svn: 99485

llvm-svn: 99484

instead of InlineFunction.

llvm-svn: 99483