| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 238634
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, subtarget features were a bitfield with the underlying type being uint64_t.
Since several targets (X86 and ARM, in particular) have hit or were very close to hitting this bound, switching the features to use a bitset.
No functional change.
The first several times this was committed (e.g. r229831, r233055), it caused several buildbot failures.
Apparently the reason for most failures was both clang and gcc's inability to deal with large numbers (> 10K) of bitset constructor calls in tablegen-generated initializers of instruction info tables.
This should now be fixed.
llvm-svn: 238192
|
|
|
|
|
|
| |
s/EncodeInstruction/encodeInstruction/
llvm-svn: 237469
|
|
|
|
|
|
| |
s/MCFixup::Create/MCFixup::create/
llvm-svn: 237468
|
|
|
|
|
|
| |
MCOperand::Create*() methods renamed to MCOperand::create*().
llvm-svn: 237275
|
|
|
|
|
|
|
| |
The buildbots are still not satisfied.
MIPS and ARM are failing (even though at least MIPS was expected to pass).
llvm-svn: 237245
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, subtarget features were a bitfield with the underlying type being uint64_t.
Since several targets (X86 and ARM, in particular) have hit or were very close to hitting this bound, switching the features to use a bitset.
No functional change.
The first two times this was committed (r229831, r233055), it caused several buildbot failures.
At least some of the ARM and MIPS ones were due to gcc/binutils issues, and should now be fixed.
llvm-svn: 237234
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is generated using clang-tidy misc-use-override check.
This command was used:
tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \
-checks='-*,misc-use-override' -header-filter='llvm|clang' \
-j=32 -fix -format
http://reviews.llvm.org/D8925
llvm-svn: 234679
|
|
|
|
|
|
|
|
| |
This reverts commit r233055.
It still causes buildbot failures (gcc running out of memory on several platforms, and a self-host failure on arm), although less than the previous time.
llvm-svn: 233068
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, subtarget features were a bitfield with the underlying type being uint64_t.
Since several targets (X86 and ARM, in particular) have hit or were very close to hitting this bound, switching the features to use a bitset.
No functional change.
The first time this was committed (r229831), it caused several buildbot failures.
At least some of the ARM ones were due to gcc/binutils issues, and should now be fixed.
Differential Revision: http://reviews.llvm.org/D8542
llvm-svn: 233055
|
|
|
|
|
|
|
| |
update all ports accordingly. Required a couple of small rewrites
in handling subtarget features during creation in PPC.
llvm-svn: 231861
|
|
|
|
| |
llvm-svn: 229841
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, subtarget features were a bitfield with the underlying type being uint64_t.
Since several targets (X86 and ARM, in particular) have hit or were very close to hitting this bound, switching the features to use a bitset.
No functional change.
Differential Revision: http://reviews.llvm.org/D7065
llvm-svn: 229831
|
|
|
|
|
|
| |
requiring the macro. NFC; LLVM edition.
llvm-svn: 229340
|
|
|
|
|
|
| |
encodings linear which can then be used to simplify some other code.
llvm-svn: 229279
|
|
|
|
|
|
|
|
| |
AdSize16/32/64 flags.
This removes a hardcoded list of instructions in the CodeEmitter. Eventually I intend to remove the predicates on the affected instructions since in any given mode two of them are valid if we supported addr32/addr16 prefixes in the assembler.
llvm-svn: 224809
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: x86 allows either ordering for the LOCK and DATA16 prefixes, but using GCC+GAS leads to different code generation than using LLVM. This change matches the order that GAS emits the x86 prefixes when a semicolon isn't used in inline assembly (see tc-i386.c comment before define LOCK_PREFIX), and helps simplify tooling that operates on the instruction's byte sequence (such as NaCl's validator). This change shouldn't have any performance impact.
Test Plan: ninja check
Reviewers: craig.topper, jvoung
Subscribers: jfb, llvm-commits
Differential Revision: http://reviews.llvm.org/D6630
llvm-svn: 224283
|
|
|
|
| |
llvm-svn: 223339
|
|
|
|
|
|
| |
the VEXShift hack that was used to access the higher bits of TSFlags.
llvm-svn: 221673
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows assembling the two new instructions, encls and enclu for the
SKX processor model.
Note the diffs are a bigger than what might think, but to fit the new
MRM_CF and MRM_D7 in things in the right places things had to be
renumbered and shuffled down causing a bit more diffs.
rdar://16228228
llvm-svn: 214460
|
|
|
|
|
|
|
|
|
|
|
| |
Passes the computed scaling factor in TSFlags rather than the old attributes.
Also removes the C++ version of computing the scaling factor (MemObjSize)
along with the asserts added by the previous patch.
No functional change.
llvm-svn: 213279
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This does not actually move the logic yet but reimplements it in the Tablegen
language. Then asserts that the new implementation results in the same value.
The next patch will remove the assert and the temporary use of the TSFlags and
remove the C++ implementation.
The formula requires a limited form of the logical left and right operators.
I implemented these with the bit-extract/insert operator (i.e. blah{bits}).
No functional change.
llvm-svn: 213278
|
|
|
|
|
|
|
|
| |
No functional change. As I was trying to understand this function, I found
that variables were reused with confusing names and the broadcast case was a
bit too implicit. Hopefully, this is an improvement.
llvm-svn: 212795
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was computing the VL/n case as:
MemObjSize = VectorByteSize / ElemByteSize / Divider * ElemByteSize
ElemByteSize not only falls out but VectorByteSize/Divider now actually
matches the definition of VL/n.
Also some formatting fixes.
llvm-svn: 212794
|
|
|
|
|
|
|
|
|
| |
1) Changed gather and scatter intrinsics. Now they are aligned with GCC built-ins. There is no more non-masked form. Masked intrinsic receives -1 if all lanes are executed.
2) I changed the function that works with intrinsics inside X86ISelLowering.cpp. I put all intrinsics in one table. I did it for INTRINSICS_W_CHAIN and plan to put all intrinsics from WO_CHAIN set to the same table in order to avoid the long-long "switch". (I wanted to use static map initialization that allowed by C++11 but I wasn't able to compile it on VS2012).
3) I added gather/scatter prefetch intrinsics.
4) I fixed MRMm encoding for masked instructions.
llvm-svn: 208522
|
|
|
|
| |
llvm-svn: 207197
|
|
|
|
|
|
|
| |
definition below all of the header #include lines, lib/Target/...
edition.
llvm-svn: 206842
|
|
|
|
|
|
|
|
|
| |
With this MC is able to handle _GLOBAL_OFFSET_TABLE_ in 64 bit mode, which is
needed for medium and large code models.
This fixes pr19470.
llvm-svn: 206793
|
|
|
|
|
|
| |
class.
llvm-svn: 203418
|
|
|
|
| |
llvm-svn: 203096
|
|
|
|
|
|
| |
handle all the FP operations. This increases format by 1 bit, but decreases opcode map by 1 bit so the TSFlags size doesn't change.
llvm-svn: 201649
|
|
|
|
|
|
| |
0xa6/0xa7, and adding MRM_C0/MRM_E0 forms. Removes 376K from the disassembler tables.
llvm-svn: 201641
|
|
|
|
|
|
|
|
|
|
| |
Original commits messages:
Add MRMXr/MRMXm form to X86 for use by instructions which treat the 'reg' field of modrm byte as a don't care value. Will allow for simplification of disassembler code.
Simplify a bunch of code by removing the need for the x86 disassembler table builder to know about extended opcodes. The modrm forms are sufficient to convey the information.
llvm-svn: 201065
|
|
|
|
|
|
|
|
| |
r201059 appears to cause a crash in a bootstrapped build of clang. Craig
isn't available to look at it right now, so I'm reverting it while he
investigates.
llvm-svn: 201064
|
|
|
|
|
|
| |
field of modrm byte as a don't care value. Will allow for simplification of disassembler code.
llvm-svn: 201059
|
|
|
|
| |
llvm-svn: 200837
|
|
|
|
|
|
| |
meaning no 0x66 prefix in any mode. Rename Opsize16->OpSize32 and OpSize->OpSize16. The classes now refer to their operand size rather than the mode in which they need a 0x66 prefix. Hopefully can merge REX_W into this as OpSize64.
llvm-svn: 200626
|
|
|
|
|
|
| |
in TSFlags.
llvm-svn: 200624
|
|
|
|
|
|
| |
TSFlags. This greatly simplifies the switch statements in the disassembler tables and the code emitters.
llvm-svn: 200522
|
|
|
|
|
|
| |
had special handling anyway and this enables a future patch.
llvm-svn: 200520
|
|
|
|
|
|
| |
for VEX encoded instructions too. This allows 32-bit addressing to work in 64-bit mode.
llvm-svn: 200516
|
|
|
|
|
|
|
|
|
| |
These should end up (in ELF) as R_X86_64_32S relocs, not R_X86_64_32.
Kill the horrid and incomplete special case and FIXME in
EncodeInstruction() and set things up so it can infer the signedness
from the ImmType just like it can the size and whether it's PC-relative.
llvm-svn: 200495
|
|
|
|
|
|
|
|
| |
The subtarget info is explicitly passed to the EncodeInstruction
method and we should use that subtarget info to influence any
encoding decisions.
llvm-svn: 200350
|
|
|
|
| |
llvm-svn: 200348
|
|
|
|
| |
llvm-svn: 199812
|
|
|
|
| |
llvm-svn: 199806
|
|
|
|
| |
llvm-svn: 199804
|
|
|
|
| |
llvm-svn: 199803
|
|
|
|
| |
llvm-svn: 199468
|
|
|
|
|
|
| |
encoded and disassembled with a segment override prefix. Fixes PR16962.
llvm-svn: 199364
|