| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
returns the start of the memory operand for an instruction.
Introduce a new "X86AddrSegment" enum to reduce # magic numbers
referring to X86 memory operand layout.
llvm-svn: 107916
|
|
|
|
| |
llvm-svn: 107898
|
|
|
|
|
|
|
| |
in the integrated assembler. Still some discussion to be
done.
llvm-svn: 107825
|
|
|
|
|
|
| |
Update VEX encoding to support those new instructions
llvm-svn: 107715
|
|
|
|
|
|
|
|
| |
- Add encode bits for VEX_W
- All 128-bit SSE 1 & SSE2 instructions that are described
in the .td file now have a AVX encoded form already working.
llvm-svn: 107365
|
|
|
|
| |
llvm-svn: 106588
|
|
|
|
|
|
|
|
|
|
|
|
| |
addresses a longstanding deficiency noted in many FIXMEs scattered
across all the targets.
This effectively moves the problem up one level, replacing eleven
FIXMEs in the targets with eight FIXMEs in CodeGen, plus one path
through FastISel where we actually supply a DebugLoc, fixing Radar
7421831.
llvm-svn: 106243
|
|
|
|
|
|
| |
immediates to avoid breaking the build.
llvm-svn: 105652
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In file included from X86InstrInfo.cpp:16:
X86GenInstrInfo.inc:2789: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2790: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2792: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2793: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2808: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2809: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2816: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2817: error: integer constant is too large for 'long' type
llvm-svn: 105524
|
|
|
|
|
|
| |
yet, only assembly encoding support.
llvm-svn: 105521
|
|
|
|
| |
llvm-svn: 105381
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instruction defines subregisters.
Any existing subreg indices on the original instruction are preserved or
composed with the new subreg index.
Also substitute multiple operands mentioning the original register by using the
new MachineInstr::substituteRegister() function. This is necessary because there
will soon be <imp-def> operands added to non read-modify-write partial
definitions. This instruction:
%reg1234:foo = FLAP %reg1234<imp-def>
will reMaterialize(%reg3333, bar) like this:
%reg3333:bar-foo = FLAP %reg333:bar<imp-def>
Finally, replace the TargetRegisterInfo pointer argument with a reference to
indicate that it cannot be NULL.
llvm-svn: 105358
|
|
|
|
| |
llvm-svn: 104421
|
|
|
|
|
|
| |
doesn't have to guess.
llvm-svn: 103194
|
|
|
|
| |
llvm-svn: 103193
|
|
|
|
| |
llvm-svn: 102577
|
|
|
|
|
|
|
|
|
|
|
| |
otherwise labels get incorrectly merged. We handled this by emitting a
".byte 0", but this isn't correct on thumb/arm targets where the text segment
needs to be a multiple of 2/4 bytes. Handle this by emitting a noop. This
is more gross than it should be because arm/ppc are not fully mc'ized yet.
This fixes rdar://7908505
llvm-svn: 102400
|
|
|
|
|
|
|
|
| |
and rename it to emitFrameIndexDebugValue.
- Teach spiller to modify DBG_VALUE instructions to reference spill slots.
llvm-svn: 102323
|
|
|
|
|
|
|
|
| |
SSEDomainFix will collapse to the domain with the lower number when it has a
choice. The SSEPackedSingle domain often has smaller instructions, so prefer
that.
llvm-svn: 99952
|
|
|
|
|
|
| |
Cross-block inference is primitive and wrong, but the pass is working otherwise.
llvm-svn: 99848
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
crossings.
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
|
|
|
|
|
|
|
|
| |
domain crossings."
This reverts commit 99345. It was breaking buildbots.
llvm-svn: 99352
|
|
|
|
|
|
|
|
|
| |
crossings.
This is work in progress. So far, SSE execution domain tables are added to
X86InstrInfo, and a skeleton pass is enabled with -sse-domain-fix.
llvm-svn: 99345
|
|
|
|
| |
llvm-svn: 96076
|
|
|
|
|
|
| |
fix swapgs to be spelled right.
llvm-svn: 96058
|
|
|
|
|
|
|
| |
addressing. This isn't complete because I need an MCContext
to generate new MCExprs.
llvm-svn: 96036
|
|
|
|
|
|
| |
is pc relative or not, mark call and branches as pcrel.
llvm-svn: 96026
|
|
|
|
|
|
|
| |
This will work better for the disassembler for modeling things
like lfence/monitor/vmcall etc.
llvm-svn: 95960
|
|
|
|
|
|
| |
great solution for the disassembler, we'll go with "plan b".
llvm-svn: 95957
|
|
|
|
| |
llvm-svn: 95949
|
|
|
|
| |
llvm-svn: 95440
|
|
|
|
| |
llvm-svn: 95410
|
|
|
|
| |
llvm-svn: 95408
|
|
|
|
|
|
| |
TSFlags directly instead of a TargetInstrDesc.
llvm-svn: 95405
|
|
|
|
|
|
|
|
| |
instructions with no operands. It can now handle
define void @test2() nounwind { ret void }
llvm-svn: 95261
|
|
|
|
|
|
| |
scheduled together.
llvm-svn: 94147
|
|
|
|
|
|
|
|
| |
where the pre-extension values are available in the subreg of the result of the extension, replace the uses of the pre-extension value with the result + extract_subreg.
For now, this pass is fairly conservative. It only perform the replacement when both the pre- and post- extension values are used in the block. It will miss cases where the post-extension values are live, but not used.
llvm-svn: 93278
|
|
|
|
|
|
|
|
|
| |
instruction is copy like where the source and destination registers can
overlap. This is to be used by the coalescable to coalesce the source and
destination registers of instructions like X86::MOVSX64rr32. Apparently
some crazy people believe the coalescer is too simple.
llvm-svn: 93210
|
|
|
|
| |
llvm-svn: 91104
|
|
|
|
|
|
|
| |
MachineBasicBlock::canFallThrough(), which is target-independent and more
thorough.
llvm-svn: 90634
|
|
|
|
| |
llvm-svn: 90608
|
|
|
|
|
|
|
|
|
| |
for all the processors where I have tried it, and even when it might not help
performance, the cost is quite low. The opportunities for duplicating
indirect branches are limited by other factors so code size does not change
much due to tail duplicating indirect branches aggressively.
llvm-svn: 90144
|
|
|
|
|
|
|
| |
it is definitely profitable to tail duplicate indirect branches for x86.
This is likely to be true to various degrees for all modern x86 processors.
llvm-svn: 89865
|
|
|
|
|
|
|
|
| |
- If destination is a physical register and it has a subreg index, use the
sub-register instead.
This fixes PR5423.
llvm-svn: 88745
|
|
|
|
|
|
|
|
| |
Provide special isLoadFromStackSlotPostFE and isStoreToStackSlotPostFE
interfaces to explicitly request checking for post-frame ptr elimination
operands. This uses a heuristic so it isn't reliable for correctness.
llvm-svn: 87047
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
machine instruction loads or stores from/to a stack slot. Unlike
isLoadFromStackSlot and isStoreFromStackSlot, the instruction may be
something other than a pure load/store (e.g. it may be an arithmetic
operation with a memory operand). This helps AsmPrinter determine when
to print a spill/reload comment.
This is only a hint since we may not be able to figure this out in all
cases. As such, it should not be relied upon for correctness.
Implement for X86. Return false by default for other architectures.
llvm-svn: 87026
|
|
|
|
|
|
|
|
|
|
| |
unfolding loads for hoisting. getOpcodeAfterMemoryUnfold returns the
opcode of the original operation without the load, not the load
itself, MachineLICM needs to know the operand index in order to get
the correct register class. Extend getOpcodeAfterMemoryUnfold to
return this information.
llvm-svn: 85622
|
|
|
|
|
|
|
| |
MachineInstr::isInvariantLoad instead, which has the benefit of being
more complete.
llvm-svn: 83696
|
|
|
|
|
|
| |
information when unfolding memory references.
llvm-svn: 83656
|
|
|
|
|
|
|
|
|
| |
implementations with a new MachineInstr::isInvariantLoad, which uses
MachineMemOperands and is target-independent. This brings MachineLICM
and other functionality to targets which previously lacked an
isInvariantLoad implementation.
llvm-svn: 83475
|