- Check getBytesToPopOnReturn().
- Eschew ST0 and ST1 for return values.
- Fix the PIC base register initialization so that it doesn't ever
fail to end up the top of the entry block.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@108039 91177308-0d34-0410-b5e6-96231b3b80d8
notes:
- The instructions are being added with dummy placeholder patterns using some 256
specifiers, this is not meant to work now, but since there are some multiclasses
generic enough to accept them, when we go for codegen, the stuff will be already
there.
- Add VEX encoding bits to support YMM
- Add MOVUPS and MOVAPS in the first round
- Use "Y" as suffix for those Instructions: MOVUPSYrr, ...
- All AVX instructions in X86InstrSSE.td will move soon to a new X86InstrAVX
file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107996 91177308-0d34-0410-b5e6-96231b3b80d8
U utils/TableGen/FastISelEmitter.cpp
--- Reverse-merging r107943 into '.':
U test/CodeGen/X86/fast-isel.ll
U test/CodeGen/X86/fast-isel-loads.ll
U include/llvm/Target/TargetLowering.h
U include/llvm/Support/PassNameParser.h
U include/llvm/CodeGen/FunctionLoweringInfo.h
U include/llvm/CodeGen/CallingConvLower.h
U include/llvm/CodeGen/FastISel.h
U include/llvm/CodeGen/SelectionDAGISel.h
U lib/CodeGen/LLVMTargetMachine.cpp
U lib/CodeGen/CallingConvLower.cpp
U lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
U lib/CodeGen/SelectionDAG/FunctionLoweringInfo.cpp
U lib/CodeGen/SelectionDAG/FastISel.cpp
U lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
U lib/CodeGen/SelectionDAG/ScheduleDAGSDNodes.cpp
U lib/CodeGen/SelectionDAG/InstrEmitter.cpp
U lib/CodeGen/SelectionDAG/TargetLowering.cpp
U lib/Target/XCore/XCoreISelLowering.cpp
U lib/Target/XCore/XCoreISelLowering.h
U lib/Target/X86/X86ISelLowering.cpp
U lib/Target/X86/X86FastISel.cpp
U lib/Target/X86/X86ISelLowering.h
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107987 91177308-0d34-0410-b5e6-96231b3b80d8
Add explicit testcases for tail calls within the same module.
Duplicate some code to humor those who think .w doesn't apply on ARM.
Leave this disabled on Thumb1, and add some comments explaining why it's hard
and won't gain much.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107851 91177308-0d34-0410-b5e6-96231b3b80d8
around everywhere, and also give it an InsertPt member, to enable isel
to operate at an arbitrary position within a block, rather than just
appending to a block.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107791 91177308-0d34-0410-b5e6-96231b3b80d8
The COPY instruction is intended to replace the target specific copy
instructions for virtual registers as well as the EXTRACT_SUBREG and
INSERT_SUBREG instructions in MachineFunctions. It won't we used in a selection
DAG.
COPY is lowered to native register copies by LowerSubregs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107529 91177308-0d34-0410-b5e6-96231b3b80d8
list of predefined instructions appear. Add some consistency checks.
Ideally, TargetOpcodes.h should be produced by TableGen from Target.td, but it
is hardly worth the effort.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107520 91177308-0d34-0410-b5e6-96231b3b80d8
Given the pattern below as an example:
list<dag> Pattern = [(set RC:$dst, (v4f32 (shufp:src3 RC:$src1,
(mem_frag addr:$src2))))];
The right reference resolving should lead to:
list<dag> Pattern = [(set VR128:$dst, (v4f32 (shufp:src3 VR128:$src1,
(mem_frag addr:$src2))))];
But was yielding:
list<dag> Pattern = [(set VR128:$dst, (v4f32 (shufp VR128:$src1,
(mem_frag addr:$src2))))];
Fix this by passing the right name when creating a new DagInit node.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@106670 91177308-0d34-0410-b5e6-96231b3b80d8
The attribute class generation support is still somewhat limited.
See the accompanying clang commit for more details.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@106174 91177308-0d34-0410-b5e6-96231b3b80d8
call must not be callee-saved; following x86, add a new
regclass to represent this. Also fixes a couple of bugs.
Still disabled by default; Thumb doesn't work yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@106053 91177308-0d34-0410-b5e6-96231b3b80d8
the machine instruction representation of the immediate value to be encoded
into an integer with similar fields as the actual VMOV instruction. This makes
things easier for the disassembler, since it can just stuff the bits into the
immediate operand, but harder for the asm printer since it has to decode the
value to be printed. Testcase for the encoding will follow later when MC has
more support for ARM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105836 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105524 91177308-0d34-0410-b5e6-96231b3b80d8
A temporary flag -arm-tail-calls defaults to off,
so there is no functional change by default.
Intrepid users may try this; simple cases work
but there are bugs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105413 91177308-0d34-0410-b5e6-96231b3b80d8
The StmtNodes generator has been generalized to allow for the
creation of DeclNodes tables as well, and another emitter was
added for DeclContexts.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105164 91177308-0d34-0410-b5e6-96231b3b80d8
of the intrinsics. The goal is to auto-generate both support for GCC-style (vector)
and ARM-style (struct of vector) intrinsics.
This is work in progress, but will be completed soon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104910 91177308-0d34-0410-b5e6-96231b3b80d8
This means that our Registers are now ordered R7, R8, R9, R10, R12, ...
Not R1, R10, R11, R12, R2, R3, ...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104745 91177308-0d34-0410-b5e6-96231b3b80d8
A Register with subregisters must also provide SubRegIndices for adressing the
subregisters. TableGen automatically inherits indices for sub-subregisters to
minimize typing.
CompositeIndices may be specified for the weirder cases such as the XMM sub_sd
index that returns the same register, and ARM NEON Q registers where both D
subregs have ssub_0 and ssub_1 sub-subregs.
It is now required that all subregisters are named by an index, and a future
patch will also require inherited subregisters to be named. This is necessary to
allow composite subregister indices to be reduced to a single index.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104704 91177308-0d34-0410-b5e6-96231b3b80d8
A Register with subregisters must also provide SubRegIndices for adressing the
subregisters. TableGen automatically inherits indices for sub-subregisters to
minimize typing.
CompositeIndices may be specified for the weirder cases such as the XMM sub_sd
index that returns the same register, and ARM NEON Q registers where both D
subregs have ssub_0 and ssub_1 sub-subregs.
It is now required that all subregisters are named by an index, and a future
patch will also require inherited subregisters to be named. This is necessary to
allow composite subregister indices to be reduced to a single index.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104654 91177308-0d34-0410-b5e6-96231b3b80d8
This passes lit tests, but I'll give it a go through the buildbots to smoke out
any remaining places that depend on the old SubRegIndex numbering.
Then I'll remove NumberHack entirely.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104615 91177308-0d34-0410-b5e6-96231b3b80d8
structure that represents a mapping without any dependencies on SubRegIndex
numbering.
This brings us closer to being able to remove the explicit SubRegIndex
numbering, and it is now possible to specify any mapping without inventing
*_INVALID register classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104563 91177308-0d34-0410-b5e6-96231b3b80d8
This is the beginning of purely symbolic subregister indices, but we need a bit
of jiggling before the explicit numeric indices can be completely removed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104492 91177308-0d34-0410-b5e6-96231b3b80d8
and %rcr_, leaving just %cr_ which is what people expect.
Updated the disassembler to support this unified register set.
Added a testcase to verify that the registers continue to be
decoded correctly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103196 91177308-0d34-0410-b5e6-96231b3b80d8
and diagnostic groups. This allows the compiler to group
diagnostics together (e.g. "Logic Warning",
"Format String Warning", etc) like the static analyzer does.
This is not exposed through anything in the compiler yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103050 91177308-0d34-0410-b5e6-96231b3b80d8
sub-register indices and outputs a single super register which is formed from
a consecutive sequence of registers.
This is used as register allocation / coalescing aid and it is useful to
represent instructions that output register pairs / quads. For example,
v1024, v1025 = vload <address>
where v1024 and v1025 forms a register pair.
This really should be modelled as
v1024<3>, v1025<4> = vload <address>
but it would violate SSA property before register allocation is done.
Currently we use insert_subreg to form the super register:
v1026 = implicit_def
v1027 - insert_subreg v1026, v1024, 3
v1028 = insert_subreg v1027, v1025, 4
...
= use v1024
= use v1028
But this adds pseudo live interval overlap between v1024 and v1025.
We can now modeled it as
v1024, v1025 = vload <address>
v1026 = REG_SEQUENCE v1024, 3, v1025, 4
...
= use v1024
= use v1026
After coalescing, it will be
v1026<3>, v1025<4> = vload <address>
...
= use v1026<3>
= use v1026
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102815 91177308-0d34-0410-b5e6-96231b3b80d8
FU per CPU arch to 32 per intinerary allowing precise modelling of quite
complex pipelines in the future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101754 91177308-0d34-0410-b5e6-96231b3b80d8
code. It used to #include the enhanced disassembly
information for the targets it supported straight
out of lib/Target/{X86,ARM,...} but now it uses a
new interface provided by MCDisassembler, and (so
far) implemented by X86 and ARM.
Also removed hacky #define-controlled initialization
of targets in edis. If clients only want edis to
initialize a limited set of targets, they can set
--enable-targets on the configure command line.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101179 91177308-0d34-0410-b5e6-96231b3b80d8
We are bound to fail! For proper disassembly, the well-known encoding bits
of the instruction must be fully specified.
This also removes pseudo instructions from considerations of disassembly,
which is a better design and less fragile than the name matchings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100899 91177308-0d34-0410-b5e6-96231b3b80d8
such that the non-VFP versions have no implicit defs of VFP registers.
If any callee-saved VFP registers are marked as having been defined, the
prologue/epilogue code will try to save and restore them.
Radar 7770432.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100892 91177308-0d34-0410-b5e6-96231b3b80d8
I also added a rule to the ARM target's Makefile to
build the ARM-specific instruction information table
for the enhanced disassembler.
I will add the test harness for all this stuff in
a separate commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100735 91177308-0d34-0410-b5e6-96231b3b80d8
argument that had to be between 0 and 7 to have any value,
firing an assert later in the AsmPrinter. Now, the
disassembler rejects instructions with out-of-range values
for that immediate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100694 91177308-0d34-0410-b5e6-96231b3b80d8
When a target instruction wants to set target-specific flags, it should simply
set bits in the TSFlags bit vector defined in the Instruction TableGen class.
This works well because TableGen resolves member references late:
class I : Instruction {
AddrMode AM = AddrModeNone;
let TSFlags{3-0} = AM.Value;
}
let AM = AddrMode4 in
def ADD : I;
TSFlags gets the expected bits from AddrMode4 in this example.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100384 91177308-0d34-0410-b5e6-96231b3b80d8
backend (ARMDecoderEmitter) which emits the decoder functions for ARM and Thumb,
and the disassembler core which invokes the decoder function and builds up the
MCInst based on the decoded Opcode.
Reviewed by Chris Latter and Bob Wilson.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100233 91177308-0d34-0410-b5e6-96231b3b80d8
doesn't need to be stable because the patterns are fully ordered.
Add a first level sort predicate that orders patterns in this
order: 1) scalar integer operations 2) scalar floating point
3) vector int 4) vector float. This is a trivial sort on their
top level pattern type so it is nice and transitive. The
benefit of doing this is that simple integer operations are
much more common than insane vector things and isel was trying
to match the big complex vector patterns before the simple
ones because the complexity of the vector operations was much
higher. Since they can't both match, it is best (for compile
time) to try the simple integer ones first.
This cuts down the # failed match attempts on real code by
quite a bit, for example, this reduces backtracks on crafty
(as a random example) from 228285 -> 188369.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99797 91177308-0d34-0410-b5e6-96231b3b80d8
patterns within the generated matcher. This works great except
that the sort fails because the relation defined isn't
transitive. I have a much simpler solution coming next, but want
to archive the code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99795 91177308-0d34-0410-b5e6-96231b3b80d8
and those derived from them. These are obnoxious because
they were written as: PatLeaf<(bitconvert). Not having an
argument was foiling adding better type checking for operand
count matching up with what was required (in this case,
bitconvert always requires an operand!)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99759 91177308-0d34-0410-b5e6-96231b3b80d8
transforming it into (add (i32 GPR), 4). This allows us to write type
generic multi patterns and have tblgen automatically drop the bitconvert
in the case when the types align. This allows us to fold an extra load
in the changed testcase.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99756 91177308-0d34-0410-b5e6-96231b3b80d8
1, 1 cases which are by-far the most frequent. This shrinks the X86
isel table from 77014 -> 74657 bytes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99740 91177308-0d34-0410-b5e6-96231b3b80d8
