| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
be the first encoded as the first feature. It then uses the CPU name to look up
features / scheduling itineray even though clients know full well the CPU name
being used to query these properties.
The fix is to just have the clients explictly pass the CPU name!
llvm-svn: 134127
|
| |
|
|
|
|
|
|
|
|
| |
Unlike Thumb1, Thumb2 does not have dedicated encodings for adjusting the
stack pointer. It can just use the normal add-register-immediate encoding
since it can use all registers as a source, not just R0-R7. The extra
instruction definitions are just duplicates of the normal instructions with
the (not well enforced) constraint that the source register was SP.
llvm-svn: 134114
|
| |
|
|
|
|
|
| |
They've been pseudos for a while now, so the decoder will never see
them in the first place.
llvm-svn: 134101
|
| |
|
|
|
|
|
| |
The tSpill and tRestore instructions are just copies of the tSTRspi and
tLDRspi instructions, respectively. Just use those directly instead.
llvm-svn: 134092
|
| |
|
|
|
|
|
|
|
| |
a temporary string object that was destroyed. This is undefined behavior and MSVC didn't like it.
This fixes over 300+ failing tests on MSVC.
Credit for this fix goes to chapuni.
llvm-svn: 134064
|
| |
|
|
|
|
| |
MCInstrItineraries) into MC.
llvm-svn: 134049
|
| |
|
|
| |
llvm-svn: 134030
|
| |
|
|
| |
llvm-svn: 134027
|
| |
|
|
| |
llvm-svn: 134026
|
| |
|
|
| |
llvm-svn: 134024
|
| |
|
|
|
|
|
|
| |
sink them into MC layer.
- Added MCInstrInfo, which captures the tablegen generated static data. Chang
TargetInstrInfo so it's based off MCInstrInfo.
llvm-svn: 134021
|
| |
|
|
| |
llvm-svn: 133979
|
| |
|
|
|
|
|
|
|
|
|
| |
Correctly parse the forms of the Thumb mov-immediate instruction:
1. 8-bit immediate 0-255.
2. 12-bit shifted-immediate.
The 16-bit immediate "movw" form is also legal with just a "mov" mnemonic,
but is not yet supported. More parser logic necessary there due to fixups.
llvm-svn: 133966
|
| |
|
|
| |
llvm-svn: 133964
|
| |
|
|
|
|
|
|
| |
operands are logically equivalent to existing registers, but happen to be printed specially. For example, an instruciton that prints d0[0] instead of s0.
Patch by Jim Grosbach.
llvm-svn: 133940
|
| |
|
|
| |
llvm-svn: 133927
|
| |
|
|
|
|
| |
into XXXGenRegisterInfo.inc.
llvm-svn: 133922
|
| |
|
|
| |
llvm-svn: 133851
|
| |
|
|
| |
llvm-svn: 133845
|
| |
|
|
|
|
|
|
| |
Sorry, this was a bad idea. Within clang these builtins are in a separate
"ARM" namespace, but the actual builtin names should clearly distinguish that
they are target specific.
llvm-svn: 133832
|
| |
|
|
| |
llvm-svn: 133825
|
| |
|
|
|
|
|
|
| |
routines.
- Rename TargetRegisterDesc to MCRegisterDesc.
llvm-svn: 133820
|
| |
|
|
|
|
|
|
|
| |
doesn't get emitted into multiple object files.
This caused linker errors when linking both libLLVMX86Desc and libLLVMX86CodeGen
into a single binary (for example when building a monolithic libLLVM shared library).
llvm-svn: 133791
|
| |
|
|
|
|
|
|
|
|
|
|
| |
target machine from those that are only needed by codegen. The goal is to
sink the essential target description into MC layer so we can start building
MC based tools without needing to link in the entire codegen.
First step is to refactor TargetRegisterInfo. This patch added a base class
MCRegisterInfo which TargetRegisterInfo is derived from. Changed TableGen to
separate register description from the rest of the stuff.
llvm-svn: 133782
|
| |
|
|
|
|
|
|
|
|
| |
Take #2. Don't piggyback on the existing config.build_mode. Instead,
define a new lit feature for each build feature we need (currently
just "asserts"). Teach both autoconf'd and cmake'd Makefiles to define
this feature within test/lit.site.cfg. This doesn't require any lit
harness changes and should be more robust across build systems.
llvm-svn: 133664
|
| |
|
|
| |
llvm-svn: 133574
|
| |
|
|
|
|
|
| |
TableGen had diagnostic printers sprinkled about in a few places. Pull them
together into a single location in Error.cpp.
llvm-svn: 133568
|
| |
|
|
| |
llvm-svn: 133470
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A RegisterTuples instance is used to synthesize super-registers by
zipping together lists of sub-registers. This is useful for generating
pseudo-registers representing register sequence constraints like 'two
consecutive GPRs', or 'an even-odd pair of floating point registers'.
The RegisterTuples def can be used in register set operations when
building register classes. That is the only way of accessing the
synthesized super-registers.
For example, the ARM QQ register class of pseudo-registers could have
been formed like this:
// Form pairs Q0_Q1, Q2_Q3, ...
def QQPairs : RegisterTuples<[qsub_0, qsub_1],
[(decimate QPR, 2),
(decimate (shl QPR, 1), 2)]>;
def QQ : RegisterClass<..., (add QQPairs)>;
Similarly, pseudo-registers representing '3 consecutive D-regs with
wraparound' look like:
// Form D0_D1_D2, D1_D2_D3, ..., D30_D31_D0, D31_D0_D1.
def DSeqTriples : RegisterTuples<[dsub_0, dsub_1, dsub_2],
[(rotl DPR, 0),
(rotl DPR, 1),
(rotl DPR, 2)]>;
TableGen automatically computes aliasing information for the synthesized
registers.
Register tuples are still somewhat experimental. We still need to see
how they interact with MC.
llvm-svn: 133407
|
| |
|
|
|
|
|
|
| |
making usage
much cleaner.
llvm-svn: 133364
|
| |
|
|
|
|
| |
This should fix the Linux buildbots.
llvm-svn: 133334
|
| |
|
|
|
|
|
| |
Reuse the CodeGenRegBank DenseMap in a few places that would build their
own or use linear search.
llvm-svn: 133333
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Targets that need to change the default allocation order should use the
AltOrders mechanism instead. See the X86 and ARM targets for examples.
The allocation_order_begin() and allocation_order_end() methods have been
replaced with getRawAllocationOrder(), and there is further support
functions in RegisterClassInfo.
It is no longer possible to insert arbitrary code into generated
register classes. This is a feature.
llvm-svn: 133332
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A register class can define AltOrders and AltOrderSelect instead of
defining method protos and bodies. The AltOrders lists can be defined
with set operations, and TableGen can verify that the alternative
allocation orders only contain valid registers.
This is currently an opt-in feature, and it is still possible to
override allocation_order_begin/end. That will not be true for long.
llvm-svn: 133320
|
| |
|
|
| |
llvm-svn: 133164
|
| |
|
|
|
|
|
|
|
| |
compares.
2^30 is actually the limit on the number of physical registers per
TargetRegisterInfo.h.
llvm-svn: 133142
|
| |
|
|
|
|
| |
This should unbreak the native ARM testers.
llvm-svn: 133141
|
| |
|
|
|
|
|
|
|
|
| |
REQUIRES: Asserts
REQUIRES: Debug
This required chaining test configuration properties. It seems like a
generally good thing to do.
llvm-svn: 133131
|
| |
|
|
|
|
| |
features like register pairs and lists with "interesting" constraints (such as ARM NEON contiguous register lists or even-odd paired registers). We need to be able to generate these instructions (often from intrinsics), but don't want to have to assign a legal type to them. Instead, we'll use an "untyped" edge to bypass the type-checking and simply ensure that the register classes match.
llvm-svn: 133106
|
| |
|
|
|
|
| |
Patch by Argyrios Kyrtzidis.
llvm-svn: 133093
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
optimizations when emitting calls to the function; instead those calls may
use faster relocations which require the function to be immediately resolved
upon loading the dynamic object featuring the call. This is useful when it
is known that the function will be called frequently and pervasively and
therefore there is no merit in delaying binding of the function.
Currently only implemented for x86-64, where it turns into a call through
the global offset table.
Patch by Dan Gohman, who assures me that he's going to add LangRef documentation
for this once it's committed.
llvm-svn: 133080
|
| |
|
|
|
|
|
|
|
| |
relationships with just scanning the (typically tiny) static lists.
At the time I wrote this code (circa 2007), TargetRegisterInfo was using a std::set to perform these queries. Switching to the static hashtables was an obvious improvement, but in reality there's no reason to do anything other than scan.
With this change, total LLC time on a whole-program 403.gcc is reduced by approximately 1.5%, almost all of which comes from a 15% reduction in LiveVariables time. It also reduces the binary size of LLC by 86KB, thanks to eliminating a bunch of very large static tables.
llvm-svn: 133051
|
| |
|
|
|
|
|
|
| |
This prepares tablegen to compute register lists from set theoretic dag
expressions. This doesn't really make any difference as long as
Target.td still declares RegisterClass::MemberList as [Register].
llvm-svn: 133043
|
| |
|
|
|
|
|
|
|
|
|
| |
Make the Elements vector private and expose an ArrayRef through
getOrder() instead. getOrder will eventually provide multiple
user-specified allocation orders.
Use the sorted member set for member and subclass tests. Clean up a lot
of ad hoc searches.
llvm-svn: 133040
|
| |
|
|
|
|
| |
are also greater than the alias.
llvm-svn: 133038
|
| |
|
|
|
|
| |
No functional change intended.
llvm-svn: 133029
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Measure the worst case number of probes for a miss instead of the less
conservative number of probes required for an insertion.
Lower the limit to < 6 probes worst case.
This doubles the size of the ARM and X86 hash tables, other targets are
unaffected. LiveVariables runs 12% faster with this change.
<rdar://problem/9598545>
llvm-svn: 132999
|
| |
|
|
|
|
| |
operands in the aliasee, don't print the alias.
llvm-svn: 132963
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make the hash tables as small as possible while ensuring that all
lookups can be done in less than 8 probes.
Cut the aliases hash table in half by only storing a < b pairs - it
is a symmetric relation.
Use larger multipliers on the initial hash function to ensure that it
properly covers the whole table, and to resolve some clustering in the
very regular ARM register bank.
This reduces the size of most of these tables by 4x - 8x. For instance,
the ARM tables shrink from 48 KB to 8 KB.
llvm-svn: 132888
|
| |
|
|
|
|
| |
These computations have been moved to CodeGenRegisters.cpp.
llvm-svn: 132887
|