Examples are VABA (Vector Absolute Difference and Accumulate), VABAL (Vector
Absolute Difference and Accumulate Long), and VABD (Vector Absolute Difference).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99628 91177308-0d34-0410-b5e6-96231b3b80d8
dispatch to the appropriate routines to handle the different interpretations of
the shift amount encoded in the imm6 field. The Vd, Vm fields are interpreted
the same between the two, though.
See, for example, A8.6.367 VQSHL, VQSHLU (immediate) for N2RegVShLFrm format and
A8.6.368 VQSHRN, VQSHRUN for N2RegVShRFrm format.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99590 91177308-0d34-0410-b5e6-96231b3b80d8
exactly two passes in that case, and don't ever need to recompute any layout,
so this is a nice baseline for relaxation performance.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99563 91177308-0d34-0410-b5e6-96231b3b80d8
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99543 91177308-0d34-0410-b5e6-96231b3b80d8
Remove much horribleness from X86InstrFormats as a result. Similar
simplifications are probably possible for other targets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99539 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99538 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99524 91177308-0d34-0410-b5e6-96231b3b80d8
now configures prerequisite projects individually but also ignores them in the
big project switch statement to avoid the incorrect warning.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99506 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99494 91177308-0d34-0410-b5e6-96231b3b80d8