| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
JCXZ should have the 0x67 prefix only if we're in 32-bit mode, so make that
appropriately conditional. And JECXZ needs the prefix instead.
llvm-svn: 198757
|
|
|
|
|
|
|
|
|
|
| |
I couldn't see how to do this sanely without splitting RETQ from RETL.
Eric says: "sad about the inability to roundtrip them now, but...".
I have no idea what that means, but perhaps it wants preserving in the
commit comment.
llvm-svn: 198756
|
|
|
|
| |
llvm-svn: 198755
|
|
|
|
| |
llvm-svn: 198754
|
|
|
|
| |
llvm-svn: 198753
|
|
|
|
|
|
|
|
|
| |
This fixes the bulk of 16-bit output, and the corresponding test case
x86-16.s now looks mostly like the x86-32.s test case that it was
originally based on. A few irrelevant instructions have been dropped,
and there are still some corner cases to be fixed in subsequent patches.
llvm-svn: 198752
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 0x66 prefix toggles between 16-bit and 32-bit addressing mode.
So in 32-bit mode it is used to switch to 16-bit addressing mode for the
following instruction, while in 16-bit mode it's the other way round — it's
used to switch to 32-bit mode instead.
Thus, emit the 0x66 prefix byte for OpSize only in 32-bit (and 64-bit) mode,
and introduce a new OpSize16 bit which is used in 16-bit mode instead.
This is just the basic infrastructure for that change; a subsequent patch
will add the new OpSize16 bit to the 32-bit instructions that need it.
Patch from David Woodhouse.
llvm-svn: 198586
|
|
|
|
|
|
|
|
|
|
|
| |
This is not really expected to work right yet. Mostly because we will
still emit the OpSize (0x66) prefix in all the wrong places, along with
a number of other corner cases. Those will all be fixed in the subsequent
commits.
Patch from David Woodhouse.
llvm-svn: 198584
|
|
|
|
|
|
|
|
|
| |
Add some tests to validate correct register selection, including a fix
to an existing test which was requiring the *wrong* output.
Patch from David Woodhouse.
llvm-svn: 198566
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
this commit as the only one on the Blamelist so I quickly reverted this.
However it was actually Nick's change who has since fixed that issue.
Original commit message:
Changed the X86 assembler for intel syntax to work with directional labels.
The X86 assembler as a separate code to parser the intel assembly syntax
in X86AsmParser::ParseIntelOperand(). This did not parse directional labels.
And if something like 1f was used as a branch target it would get an
"Unexpected token" error.
The fix starts in X86AsmParser::ParseIntelExpression() in the case for
AsmToken::Integer, it needs to grab the IntVal from the current token
then look for a 'b' or 'f' following an Integer. Then it basically needs to
do what is done in AsmParser::parsePrimaryExpr() for directional
labels. It saves the MCExpr it creates in the IntelExprStateMachine
in the Sym field.
When it returns to X86AsmParser::ParseIntelOperand() it looks
for a non-zero Sym field in the IntelExprStateMachine and if
set it creates a memory operand not an immediate operand
it would normally do for the Integer.
rdar://14961158
llvm-svn: 197744
|
|
|
|
|
|
| |
directional labels. Because it doesn't work for windows :)
llvm-svn: 197731
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The X86 assembler has a separate code to parser the intel assembly syntax
in X86AsmParser::ParseIntelOperand(). This did not parse directional labels.
And if something like 1f was used as a branch target it would get an
"Unexpected token" error.
The fix starts in X86AsmParser::ParseIntelExpression() in the case for
AsmToken::Integer, it needs to grab the IntVal from the current token
then look for a 'b' or 'f' following the Integer. Then it basically needs to
do what is done in AsmParser::parsePrimaryExpr() for directional
labels. It saves the MCExpr it creates in the IntelExprStateMachine
in the Sym field.
When it returns to X86AsmParser::ParseIntelOperand() it looks
for a non-zero Sym field in the IntelExprStateMachine and if
set it creates a memory operand not an immediate operand
it would normally do for the Integer.
rdar://14961158
llvm-svn: 197728
|
|
|
|
| |
llvm-svn: 197255
|
|
|
|
| |
llvm-svn: 196339
|
|
|
|
| |
llvm-svn: 196334
|
|
|
|
| |
llvm-svn: 195682
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Mikulas Patocka. I added the test. I checked that for cpu names that
gas knows about, it also doesn't generate nopl.
The modified cpus:
i686 - there are i686-class CPUs that don't have nopl: Via c3, Transmeta
Crusoe, Microsoft VirtualBox - see
https://bbs.archlinux.org/viewtopic.php?pid=775414
k6, k6-2, k6-3, winchip-c6, winchip2 - these are 586-class CPUs
via c3 c3-2 - see https://bugs.archlinux.org/task/19733 as a proof that
Via c3 and c3-Nehemiah don't have nopl
llvm-svn: 195679
|
|
|
|
|
|
|
|
|
|
| |
On darwin, when trying to create compact unwind info, a .cfi_cfa_def
directive would case an llvm_unreachable() to be hit. Back off when we
see this directive and generate the regular DWARF style eh_frame.
rdar://15406518
llvm-svn: 194285
|
|
|
|
|
|
| |
instructions to parse either GR32 or GR64 without resorting to duplicating instructions.
llvm-svn: 192567
|
|
|
|
|
|
| |
disassembler tables. Add PINSRWrr64i to complement the AVX version.
llvm-svn: 192565
|
|
|
|
| |
llvm-svn: 192341
|
|
|
|
|
|
| |
Can be done with InstAlias instead. Unfortunately, this was causing printer to use 'vmovq' or 'vmovd' based on what was parsed. To cleanup the inconsistencies convert all 'vmovd' with 64-bit registers to 'vmovq', but provide an alias so that 'vmovd' will still parse.
llvm-svn: 192171
|
|
|
|
|
|
|
|
| |
register moves should be switched from using the MRMSrcReg form to the MRMDestReg form if the source register is a 64-bit extended register and the destination register is not.
This allows the instruction to be encoded using the 2-byte VEX form instead of the 3-byte VEX form. The GNU assembler has similar behavior and instruction selection already does this.
llvm-svn: 192088
|
|
|
|
| |
llvm-svn: 191874
|
|
|
|
| |
llvm-svn: 191633
|
|
|
|
|
|
| |
cases from switch.
llvm-svn: 191632
|
|
|
|
|
|
| |
Phabricator code review is located here: http://llvm-reviews.chandlerc.com/D1750
llvm-svn: 191539
|
|
|
|
|
|
| |
Phabricator code review is located at: http://llvm-reviews.chandlerc.com/D1759
llvm-svn: 191481
|
|
|
|
|
|
|
| |
Also assembly/disassembly tests, and for sha256rnds2, aliases with an explicit
xmm0 dependency.
llvm-svn: 190754
|
|
|
|
|
|
|
|
|
| |
Add basic assembly/disassembly support for the first Intel SHA
instruction 'sha1rnds4'. Also includes feature flag, and test cases.
Support for the remaining instructions will follow in a separate patch.
llvm-svn: 190611
|
|
|
|
|
|
| |
Added parsing of mask register and "zeroing" semantic, like {%k1} {z}.
llvm-svn: 190595
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: MASM let's you do stuff like 'MOV FS:20, EAX' and 'MOV EAX, FS:20'
Reviewers: craig.topper, rnk
Reviewed By: rnk
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1470
llvm-svn: 189407
|
|
|
|
| |
llvm-svn: 188899
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Instead of setting the suffixes in a bunch of places, just set one master
list in the top-level config. We now only modify the suffix list in a few
suites that have one particular unique suffix (.ml, .mc, .yaml, .td, .py).
- Aside from removing the need for a bunch of lit.local.cfg files, this enables
4 tests that were inadvertently being skipped (one in
Transforms/BranchFolding, a .s file each in DebugInfo/AArch64 and
CodeGen/PowerPC, and one in CodeGen/SI which is now failing and has been
XFAILED).
- This commit also fixes a bunch of config files to use config.root instead of
older copy-pasted code.
llvm-svn: 188513
|
|
|
|
| |
llvm-svn: 187576
|
|
|
|
|
|
| |
have gone in lately.
llvm-svn: 187188
|
|
|
|
|
|
| |
normal movsl instead.
llvm-svn: 186924
|
|
|
|
|
|
|
|
| |
absolute address encoded in the instruction.
rdar://8612627 and rdar://14299221
llvm-svn: 186878
|
|
|
|
|
|
| |
suppressing some of the aliases from being emitted by the asm printer.
llvm-svn: 186869
|
|
|
|
| |
llvm-svn: 185554
|
|
|
|
|
|
|
|
| |
For decoding, keep the current behavior of always decoding these as their REP
versions. In the future, this could be improved to recognize the cases where
these behave as XACQUIRE and XRELEASE and decode them as such.
llvm-svn: 184207
|
|
|
|
| |
llvm-svn: 183907
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The issue was that the MatchingInlineAsm and VariantID args to the
MatchInstructionImpl function weren't being set properly. Specifically, when
parsing intel syntax, the parser thought it was parsing inline assembly in the
at&t dialect; that will never be the case.
The crash was caused when the emitter tried to emit the instruction, but the
operands weren't set. When parsing inline assembly we only set the opcode, not
the operands, which is used to lookup the instruction descriptor.
rdar://13854391 and PR15945
Also, this commit reverts r176036. Now that we're correctly parsing the intel
syntax the pushad/popad don't match properly. I've reimplemented that fix using
a MnemonicAlias.
llvm-svn: 181620
|
|
|
|
|
|
| |
rdar://13854369 and PR15944
llvm-svn: 181564
|
|
|
|
| |
llvm-svn: 180058
|
|
|
|
|
|
|
| |
AT&T dialect. Test case for r179804 as well.
rdar://13674398 and PR13340.
llvm-svn: 179813
|
|
|
|
|
|
|
|
|
|
|
| |
unable to handle cases such as __asm mov eax, 8*-8.
This patch also attempts to simplify the state machine. Further, the error
reporting has been improved. Test cases included, but more will be added to
the clang side shortly.
rdar://13668445
llvm-svn: 179719
|
|
|
|
|
|
|
| |
As these two instructions in AVX extension are privileged instructions for
special purpose, it's only expected to be used in inlined assembly.
llvm-svn: 179266
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
memory operands.
Essentially, this layers an infix calculator on top of the parsing state
machine. The scale on the index register is still expected to be an immediate
__asm mov eax, [eax + ebx*4]
and will not work with more complex expressions. For example,
__asm mov eax, [eax + ebx*(2*2)]
The plus and minus binary operators assume the numeric value of a register is
zero so as to not change the displacement. Register operands should never
be an operand for a multiply or divide operation; the scale*indexreg
expression is always replaced with a zero on the operand stack to prevent
such a case.
rdar://13521380
llvm-svn: 178881
|
|
|
|
| |
llvm-svn: 178314
|