| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 105792
|
| |
|
|
|
|
| |
providing more ways to factor out commonality from the records.
llvm-svn: 105776
|
| |
|
|
| |
llvm-svn: 105769
|
| |
|
|
|
|
| |
This will be used primarily by NEON shift intrinsics.
llvm-svn: 105733
|
| |
|
|
| |
llvm-svn: 105726
|
| |
|
|
|
|
|
|
| |
codegen.
Parenthesize macro args
llvm-svn: 105682
|
| |
|
|
|
|
|
|
| |
constant arguments
Handle extract hi/lo with common code
llvm-svn: 105666
|
| |
|
|
|
|
| |
immediates to avoid breaking the build.
llvm-svn: 105652
|
| |
|
|
| |
llvm-svn: 105600
|
| |
|
|
|
|
| |
save some c++ code in CGBuiltins.
llvm-svn: 105598
|
| |
|
|
|
|
|
| |
fix vcvt naming
handle vdup, vcombine with generic vector code
llvm-svn: 105588
|
| |
|
|
| |
llvm-svn: 105531
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 105519
|
| |
|
|
| |
llvm-svn: 105496
|
| |
|
|
| |
llvm-svn: 105488
|
| |
|
|
| |
llvm-svn: 105461
|
| |
|
|
|
|
| |
lighten the load on clang.
llvm-svn: 105456
|
| |
|
|
|
|
| |
Add skeleton of support for emitting the list of prototypes for BuiltinsARM.def
llvm-svn: 105443
|
| |
|
|
| |
llvm-svn: 105416
|
| |
|
|
|
|
|
|
|
| |
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.
llvm-svn: 105413
|
| |
|
|
|
|
|
|
| |
those functions which can use
generic vector operators rather than __builtin_neon_*
llvm-svn: 105380
|
| |
|
|
| |
llvm-svn: 105349
|
| |
|
|
| |
llvm-svn: 105318
|
| |
|
|
| |
llvm-svn: 105316
|
| |
|
|
| |
llvm-svn: 105315
|
| |
|
|
| |
llvm-svn: 105307
|
| |
|
|
| |
llvm-svn: 105297
|
| |
|
|
|
|
|
|
| |
The StmtNodes generator has been generalized to allow for the
creation of DeclNodes tables as well, and another emitter was
added for DeclContexts.
llvm-svn: 105164
|
| |
|
|
|
|
| |
Also verify that all subregister indices compose unambiguously.
llvm-svn: 105064
|
| |
|
|
| |
llvm-svn: 104927
|
| |
|
|
| |
llvm-svn: 104912
|
| |
|
|
|
|
|
|
|
|
|
| |
description
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.
llvm-svn: 104910
|
| |
|
|
| |
llvm-svn: 104874
|
| |
|
|
| |
llvm-svn: 104845
|
| |
|
|
|
|
| |
reliably.
llvm-svn: 104806
|
| |
|
|
| |
llvm-svn: 104755
|
| |
|
|
|
|
|
| |
This means that our Registers are now ordered R7, R8, R9, R10, R12, ...
Not R1, R10, R11, R12, R2, R3, ...
llvm-svn: 104745
|
| |
|
|
| |
llvm-svn: 104741
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 104704
|
| |
|
|
|
|
| |
This reverts commit 104654.
llvm-svn: 104660
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 104654
|
| |
|
|
| |
llvm-svn: 104650
|
| |
|
|
| |
llvm-svn: 104628
|
| |
|
|
|
|
|
|
|
|
|
| |
instead.
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.
llvm-svn: 104615
|
| |
|
|
| |
llvm-svn: 104571
|
| |
|
|
| |
llvm-svn: 104567
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 104563
|
| |
|
|
|
|
|
| |
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.
llvm-svn: 104492
|