| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
For now I only updated the _alt variants. The main variants are used by
codegen and that will need a bit more work to trigger.
<rdar://problem/17492620>
llvm-svn: 212114
|
|
|
|
|
|
|
|
|
| |
For now I used a separate template for these sub-vector/tuple broadcasts
rather than sharing the mem variants with avx512_int_broadcast_rm.
<rdar://problem/17402869>
llvm-svn: 211828
|
|
|
|
|
|
|
|
| |
The *_alt defs for vcmp are used by the InstParser (the asm string in the main
def is used by the InstPrinter) . The former was accepting vector registers
as destination rather than mask registers.
llvm-svn: 211750
|
|
|
|
|
|
| |
Another step in fixing pr19185.
llvm-svn: 211416
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We would get confused by '@' characters in symbol names, we would
mistake the text following them for the variant kind.
When an identifier a string, the variant kind will never show up inside
of it. Instead, check to see if there is a variant following the
string.
This fixes PR19965.
llvm-svn: 211249
|
|
|
|
|
|
|
|
|
|
|
| |
Note that I followed the AVX2 convention here and didn't add LLVM intrinsics
for stores. These can be generated with the nontemporal hint on LLVM IR
stores (see new test). The GCC builtins are lowered directly into nontemporal
stores.
<rdar://problem/17082571>
llvm-svn: 211176
|
|
|
|
|
|
|
| |
Use the max 64-bit element size with EVEX_CD8. This should work since element
size is ignored for a full-vector access (FVM).
llvm-svn: 211175
|
|
|
|
|
|
| |
Along with the corresponding intrinsic and tests.
llvm-svn: 210543
|
|
|
|
|
|
| |
We can just split targets_to_build in one place and make it immutable.
llvm-svn: 210496
|
|
|
|
| |
llvm-svn: 208607
|
|
|
|
|
|
| |
Added encoding tests.
llvm-svn: 206884
|
|
|
|
|
|
| |
By Robert Khasanov rob.khasanov@gmail.com
llvm-svn: 204906
|
|
|
|
| |
llvm-svn: 204421
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Given
bar = foo + 4
.long bar
MC would eat the 4. GNU as includes it in the relocation. The rule seems to be
that a variable that defines a symbol is used in the relocation and one that
does not define a symbol is evaluated and the result included in the relocation.
Fixing this unfortunately required some other changes:
* Since the variable is now evaluated, it would prevent the ELF writer from
noticing the weakref marker the elf streamer uses. This patch then replaces
that with a VariantKind in MCSymbolRefExpr.
* Using VariantKind then requires us to look past other VariantKind to see
.weakref bar,foo
call bar@PLT
doing this also fixes
zed = foo +2
call zed@PLT
so that is a good thing.
* Looking past VariantKind means that the relocation selection has to use
the fixup instead of the target.
This is a reboot of the previous fixes for MC. I will watch the sanitizer
buildbot and wait for a build before adding back the previous fixes.
llvm-svn: 204294
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes the implementation of local directional labels to use a dedicated
map. With that it can then just use CreateTempSymbol, which is what the rest
of MC uses.
CreateTempSymbol doesn't do a great job at making sure the names are unique
(or being efficient when the names are not needed), but that should probably
be fixed in a followup patch.
This fixes pr18928.
llvm-svn: 203826
|
|
|
|
| |
llvm-svn: 203790
|
|
|
|
|
|
|
|
| |
packed instructions, added encoding tests for them.
By Robert Khazanov.
llvm-svn: 203098
|
|
|
|
| |
llvm-svn: 203096
|
|
|
|
|
|
|
|
|
| |
We were dropping the displacement on the floor if we also had some
immediate offset.
Should fix PR19033.
llvm-svn: 202774
|
|
|
|
|
|
|
|
| |
Nis Zinovy (zinovy.y.nis@intel.com)
Fixed truncate i32 to i1; a test will be provided in the next commit.
llvm-svn: 201757
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
fixed encoding of VEXTRACTPS instruction.
llvm-svn: 201134
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
the << and >> bitwise operators.
rdar://15975725
llvm-svn: 200896
|
|
|
|
| |
llvm-svn: 200837
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
1. test that inlineasm works
2. test that relaxable instructions are re-encoded in the correct mode.
llvm-svn: 200351
|
|
|
|
|
|
|
| |
Placed the MC variant diagnostics in the wrong directory accidentally. Move
them into their respective architecture specific directories.
llvm-svn: 200161
|
|
|
|
|
|
|
|
|
| |
registers in memory addresses that do not match the index register. As it does
for .att_syntax.
rdar://15887380
llvm-svn: 199948
|
|
|
|
|
|
|
|
|
|
|
| |
scale factors in memory addresses. As it does for .att_syntax.
It was producing:
Assertion failed: (((Scale == 1 || Scale == 2 || Scale == 4 || Scale == 8)) && "Invalid scale!"), function CreateMem, file /Volumes/SandBox/llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp, line 1133.
rdar://14967214
llvm-svn: 199942
|
|
|
|
| |
llvm-svn: 199809
|
|
|
|
| |
llvm-svn: 199808
|
|
|
|
| |
llvm-svn: 199807
|
|
|
|
| |
llvm-svn: 199806
|
|
|
|
| |
llvm-svn: 199805
|
|
|
|
| |
llvm-svn: 199804
|
|
|
|
| |
llvm-svn: 199803
|
|
|
|
| |
llvm-svn: 199648
|
|
|
|
| |
llvm-svn: 199477
|
|
|
|
| |
llvm-svn: 199476
|
|
|
|
|
|
| |
instead of 'q'
llvm-svn: 199474
|
|
|
|
|
|
| |
encoded and disassembled with a segment override prefix. Fixes PR16962.
llvm-svn: 199364
|
|
|
|
|
|
|
|
| |
the | and & bitwise operators.
rdar://15570412
llvm-svn: 199323
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This finishes the job started in r198756, and creates separate opcodes for
64-bit vs. 32-bit versions of the rest of the RET instructions too.
LRETL/LRETQ are interesting... I can't see any justification for their
existence in the SDM. There should be no 'LRETL' in 64-bit mode, and no
need for a REX.W prefix for LRETQ. But this is what GAS does, and my
Sandybridge CPU and an Opteron 6376 concur when tested as follows:
asm __volatile__("pushq $0x1234\nmovq $0x33,%rax\nsalq $32,%rax\norq $1f,%rax\npushq %rax\nlretl $8\n1:");
asm __volatile__("pushq $1234\npushq $0x33\npushq $1f\nlretq $8\n1:");
asm __volatile__("pushq $0x33\npushq $1f\nlretq\n1:");
asm __volatile__("pushq $0x1234\npushq $0x33\npushq $1f\nlretq $8\n1:");
cf. PR8592 and commit r118903, which added LRETQ. I only added LRETIQ to
match it.
I don't quite understand how the Intel syntax parsing for ret
instructions is working, despite r154468 allegedly fixing it. Aren't the
explicitly sized 'retw', 'retd' and 'retq' supposed to work? I have at
least made the 'lretq' work with (and indeed *require*) the 'q'.
llvm-svn: 199106
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The target specific parser should return `false' if the target AsmParser handles
the directive, and `true' if the generic parser should handle the directive.
Many of the target specific directive handlers would `return Error' which does
not follow these semantics. This change simply changes the target specific
routines to conform to the semantis of the ParseDirective correctly.
Conformance to the semantics improves diagnostics emitted for the invalid
directives. X86 is taken as a sample to ensure that multiple diagnostics are
not presented for a single error.
llvm-svn: 199068
|
|
|
|
|
|
|
|
| |
They do *different* things to %esp, so they are not equivalent.
Rename PUSHi8 to PUSH32i8 and add the missing PUSH16i8.
llvm-svn: 198761
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can't do a perfect job here. We *have* to allow (%dx) even in 64-bit
mode, for example, because it might be used for an unofficial form of
the in/out instructions. We actually want to do a better job of validation
*later*. Perhaps *instead* of doing it where we are at the moment.
But for now, doing what validation we *can* do in the place that the code
already has its validation, is an improvement.
llvm-svn: 198760
|
|
|
|
|
|
|
|
|
|
| |
It seems there is no separate instruction class for having AdSize *and*
OpSize bits set, which is required in order to disambiguate between all
these instructions. So add that to the disassembler.
Hm, perhaps we do need an AdSize16 bit after all?
llvm-svn: 198759
|
|
|
|
|
|
|
|
|
| |
Where "where possible" means that it's an immediate value and it's below
0x10000. In fact GAS will either truncate or error with larger values,
and will insist on using the addr32 prefix to get 32-bit addressing. So
perhaps we should do that, in a later patch.
llvm-svn: 198758
|