| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
cases to be submitted on clang side shortly.
rdar://13663768 and PR15760
llvm-svn: 179655
|
|
|
|
| |
llvm-svn: 179611
|
|
|
|
| |
llvm-svn: 179610
|
|
|
|
| |
llvm-svn: 179607
|
|
|
|
|
|
|
| |
change intended. Test case previously added in r178568.
Part of rdar://13611297
llvm-svn: 179425
|
|
|
|
|
|
| |
when parsing MS-style inline assembly. No functional change intended.
llvm-svn: 179407
|
|
|
|
|
|
|
|
| |
is a follow on to r179393 and r179399. Test case to be added on
the clang side.
Part of rdar://13453209
llvm-svn: 179403
|
|
|
|
|
|
|
| |
is a follow on to r179393. Test case to be added on the clang side.
Part of rdar://13453209
llvm-svn: 179399
|
|
|
|
|
|
|
|
|
| |
immediate displacement. Specifically, add support for generating the proper IR.
We've been able to parse this for some time now. Test case to be added on the
clang side.
Part of rdar://13453209
llvm-svn: 179393
|
|
|
|
|
|
|
|
| |
variables that use namespace alias qualifiers. Test case coming on clang side
shortly.
Part of rdar://13499009
llvm-svn: 179343
|
|
|
|
|
|
|
| |
namespace alias qualifiers. Test case coming on clang side shortly.
Part of rdar://13499009
llvm-svn: 179339
|
|
|
|
|
|
|
|
| |
can build up the identifier string. No test case as support for looking up
these type of identifiers hasn't been implemented on the clang side.
Part of rdar://13499009
llvm-svn: 179336
|
|
|
|
|
|
|
|
| |
specific logic. This makes the code much less fragile. Test case coming on the
clang side in a moment.
rdar://13634327
llvm-svn: 179323
|
|
|
|
|
|
|
|
| |
wasn't always the start of the operand. If there was a symbol reference, then
Start pointed to that token. It's very likely there are other places that need
to be updated.
llvm-svn: 179210
|
|
|
|
| |
llvm-svn: 179205
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test cases that regressed due to r179115, plus a few more, were added in
r179182. Original commit message below:
[ms-inline asm] Use parsePrimaryExpr in lieu of parseExpression if we need to
parse an identifier. Otherwise, parseExpression may parse multiple tokens,
which makes it impossible to properly compute an immediate displacement.
An example of such a case is the source operand (i.e., [Symbol + ImmDisp]) in
the below example:
__asm mov eax, [Symbol + ImmDisp]
Part of rdar://13611297
llvm-svn: 179187
|
|
|
|
| |
llvm-svn: 179129
|
|
|
|
| |
llvm-svn: 179125
|
|
|
|
| |
llvm-svn: 179120
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parse an identifier. Otherwise, parseExpression may parse multiple tokens,
which makes it impossible to properly compute an immediate displacement.
An example of such a case is the source operand (i.e., [Symbol + ImmDisp]) in
the below example:
__asm mov eax, [Symbol + ImmDisp]
The existing test cases exercise this patch.
rdar://13611297
llvm-svn: 179115
|
|
|
|
|
|
|
|
|
|
|
| |
rather than deriving the StringRef from the Start and End SMLocs.
Using the Start and End SMLocs works fine for operands such as [Symbol], but
not for operands such as [Symbol + ImmDisp]. All existing test cases that
reference a variable exercise this patch.
rdar://13602265
llvm-svn: 179109
|
|
|
|
|
|
| |
rdar://13521249
llvm-svn: 179030
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
qualifiers.
This patch only adds support for parsing these identifiers in the
X86AsmParser. The front-end interface isn't capable of looking up
these identifiers at this point in time. The end result is the
compiler now errors during object file emission, rather than at
parse time. Test case coming shortly.
Part of rdar://13499009 and PR13340
llvm-svn: 178566
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expression. Specifically, this syntax:
ImmDisp [ BaseReg + Scale*IndexReg + Disp ]
We don't currently support:
ImmDisp [ Symbol ]
rdar://13518671
llvm-svn: 178186
|
|
|
|
|
|
|
| |
logic as a QOI cleanup. No functional change. Tests already in place.
rdar://13456414
llvm-svn: 177446
|
|
|
|
|
|
|
|
|
|
| |
an X86Operand, but also performs a Sema lookup and adds the sizing directive
when appropriate. Use this when parsing a bracketed statement. This is
necessary to get the instruction matching correct as well. Test case coming
on clang side.
rdar://13455408
llvm-svn: 177439
|
|
|
|
|
|
|
| |
logic as a QOI cleanup.
rdar://13445327
llvm-svn: 177413
|
|
|
|
|
|
|
| |
parsed one. Test case coming shortly.
rdar://13446980
llvm-svn: 177347
|
|
|
|
|
|
| |
immediate.
llvm-svn: 177243
|
|
|
|
| |
llvm-svn: 177242
|
|
|
|
| |
llvm-svn: 177135
|
|
|
|
| |
llvm-svn: 176341
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
s/AddDirectiveHandler/addDirectiveHandler/
s/ParseMSInlineAsm/parseMSInlineAsm/
s/ParseIdentifier/parseIdentifier/
s/ParseStringToEndOfStatement/parseStringToEndOfStatement/
s/ParseEscapedString/parseEscapedString/
s/EatToEndOfStatement/eatToEndOfStatement/
s/ParseExpression/parseExpression/
s/ParseParenExpression/parseParenExpression/
s/ParseAbsoluteExpression/parseAbsoluteExpression/
s/CheckForValidSection/checkForValidSection/
http://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly
No functional change intended.
llvm-svn: 175675
|
|
|
|
| |
llvm-svn: 175312
|
|
|
|
|
|
| |
'SIZE' and 'LENGTH' operators.
llvm-svn: 172773
|
|
|
|
|
|
| |
Part of rdar://12576868
llvm-svn: 172743
|
|
|
|
|
|
|
| |
have an arbitrary ordering of the base register, index register and displacement.
rdar://12527141
llvm-svn: 172484
|
|
|
|
| |
llvm-svn: 172157
|
|
|
|
|
|
| |
r172121.
llvm-svn: 172148
|
|
|
|
|
|
| |
Part of rdar://12991541
llvm-svn: 172121
|
|
|
|
|
|
|
| |
address space. Reordered the EmitULEB128IntValue arguments to
make this easier.
llvm-svn: 171949
|
|
|
|
|
|
|
|
|
|
| |
This is necessary not only for representing empty ranges, but for handling
multibyte characters in the input. (If the end pointer in a range refers to
a multibyte character, should it point to the beginning or the end of the
character in a char array?) Some of the code in the asm parsers was already
assuming this anyway.
llvm-svn: 171765
|
|
|
|
|
|
| |
its only user, is gone.
llvm-svn: 170699
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
|
|
|
|
|
|
|
|
|
| |
When an instruction as written requires 32-bit mode and we're assembling
in 64-bit mode, or vice-versa, issue a more specific diagnostic about
what's wrong.
rdar://12700702
llvm-svn: 167937
|
|
|
|
|
|
|
| |
equivalent to [expr1 + expr2]. See test cases for more examples.
rdar://12470392
llvm-svn: 166949
|
|
|
|
| |
llvm-svn: 166819
|
|
|
|
|
|
| |
Part of rdar://12576868
llvm-svn: 166792
|
|
|
|
|
|
| |
Part of rdar://12576868
llvm-svn: 166790
|