| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 199807
|
|
|
|
| |
llvm-svn: 199806
|
|
|
|
| |
llvm-svn: 199805
|
|
|
|
| |
llvm-svn: 199804
|
|
|
|
| |
llvm-svn: 199803
|
|
|
|
| |
llvm-svn: 199477
|
|
|
|
| |
llvm-svn: 199476
|
|
|
|
|
|
| |
encoded and disassembled with a segment override prefix. Fixes PR16962.
llvm-svn: 199364
|
|
|
|
|
|
|
|
| |
the | and & bitwise operators.
rdar://15570412
llvm-svn: 199323
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 198013
|
|
|
|
|
|
|
|
|
|
|
| |
That's what it actually means, and with 16-bit support it's going to be
a little more relevant since in a few corner cases we may actually want
to distinguish between 16-bit and 32-bit mode (for example the bare 'push'
aliases to pushw/pushl etc.)
Patch by David Woodhouse
llvm-svn: 197768
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
This makes the code a little more idiomatic.
No change in behaviour.
llvm-svn: 196113
|
|
|
|
|
|
|
|
|
| |
- Actually abort when an error occurred.
- Check that the frontend lookup worked when parsing length/size/type operators.
Tested by a clang test. PR18096.
llvm-svn: 196044
|
|
|
|
|
|
| |
instructions to parse either GR32 or GR64 without resorting to duplicating instructions.
llvm-svn: 192567
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'Deprecated' class allows you to specify a SubtargetFeature that the
instruction is deprecated on.
The 'ComplexDeprecationPredicate' class allows you to define a custom
predicate that is called to check for deprecation.
For example:
ComplexDeprecationPredicate<"MCR">
would mean you would have to define the following function:
bool getMCRDeprecationInfo(MCInst &MI, MCSubtargetInfo &STI,
std::string &Info)
Which returns 'false' for not deprecated, and 'true' for deprecated
and store the warning message in 'Info'.
The MCTargetAsmParser constructor was chaned to take an extra argument of
the MCInstrInfo class, so out-of-tree targets will need to be changed.
llvm-svn: 190598
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
overrides to remove forwarding in the X86AsmParser code itself. No functional change.
llvm-svn: 189205
|
|
|
|
|
|
| |
existing functions.
llvm-svn: 189204
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
memory offset instructions.
-Assembly parser now properly check the size of the memory operation specified in intel syntax. So 'mov word ptr [5], al' is no longer accepted.
-x86-32 disassembly of these instructions no longer sign extends the 32-bit address immediate based on size.
-Intel syntax printing prints the ptr size and places brackets around the address immediate.
Known remaining issues with these instructions:
-Segment override prefix is not supported. PR16962 and PR16961.
-Immediate size should be changed by address size prefix.
llvm-svn: 189201
|
|
|
|
| |
llvm-svn: 187986
|
|
|
|
|
|
|
| |
Added 512-bit operands printing.
Added instruction formats for KNL instructions.
llvm-svn: 187324
|
|
|
|
|
|
|
|
| |
asm variant.
This removes the need to store the asm variant in each row of the single table that existed before. Shaves ~16K off the size of X86AsmParser.o.
llvm-svn: 187026
|
|
|
|
|
|
| |
read in asserts.
llvm-svn: 181689
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
constructor enables
Patch by Robert Wilhelm.
llvm-svn: 181138
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the "identifier" parsed by the frontend callback by skipping forward
until we've consumed a token that ends at the point dictated by the
callback.
In addition, inform the callback when it's parsing an unevaluated
operand (e.g. mov eax, LENGTH A::x) as opposed to an evaluated one
(e.g. mov eax, [A::x]).
This commit depends on a clang commit.
llvm-svn: 180978
|
|
|
|
|
|
| |
Disp will always be one of MCSymbolRefExpr or MCConstantExpr, and never NULL.
llvm-svn: 180059
|
|
|
|
|
|
|
| |
the MCParsedAsmOperand.
Part of rdar://13663589
llvm-svn: 180054
|
|
|
|
| |
llvm-svn: 180044
|
|
|
|
|
|
|
|
| |
now taken care of by the frontend, which allows us to parse arbitrary C/C++
variables.
Part of rdar://13663589
llvm-svn: 180037
|
|
|
|
|
|
|
| |
change indended.
Part of rdar://13663589
llvm-svn: 180028
|
|
|
|
| |
llvm-svn: 179875
|
|
|
|
|
|
|
| |
indended.
Part of rdar://13663589
llvm-svn: 179871
|
|
|
|
|
|
| |
qualifiers don't necessarily begin with an identifier (e.g., ::foo::bar).
llvm-svn: 179867
|
|
|
|
| |
llvm-svn: 179866
|
|
|
|
| |
llvm-svn: 179865
|
|
|
|
| |
llvm-svn: 179856
|
|
|
|
| |
llvm-svn: 179765
|
|
|
|
| |
llvm-svn: 179764
|
|
|
|
| |
llvm-svn: 179724
|
|
|
|
|
|
|
|
|
|
|
| |
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
|