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
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
added back in by X86AsmPrinter::printIntelMemReference() during codegen.
Previously, this following example
void t() {
int i;
__asm mov eax, [i]
}
would generate the below assembly
mov eax, dword ptr [[eax]]
which resulted in a fatal error when compiling. Test case coming on the
clang side.
rdar://13444264
llvm-svn: 177440
GNU as rejects them and there are configure scripts in the wild that check if
the assembler rejects ".align 3" to determine whether the alignment is in bytes
or powers of two.
llvm-svn: 175360
Input/Output rewrite to the same location. Make sure the SizeDirective rewrite
is performed first. This also ensure the sort algorithm is stable.
llvm-svn: 175317
the body does not use them and it appears the body has positional parameters.
This can cause unexpected results as in the added test case. As the darwin
version of gas(1) which only supported positional parameters, happened to
ignore the named parameters. Now that we want to support both styles of
macros we issue a warning in this specific case.
rdar://12861644
llvm-svn: 173199
// FIXME: Constraints are hard coded to 'm', but we need an 'r'
// constraint for addressof. This needs to be cleaned up!
Test cases are already in place. Specifically,
clang/test/CodeGen/ms-inline-asm.c t15(), t16(), and t24().
llvm-svn: 172569
After discussing the refactoring with Jim and Daniel, the following changes were
made:
* All generic directive parsing is now done by AsmParser itself. The previous
division between it and GenericAsmParser did not have clear boundaries and
just produced unnatural code of GenericAsmParser juggling the internals of
AsmParser through an interface.
The division of responsibilities is now clear: target-specific directives,
other extensions (used by platform-specific parseres), and generic directives.
* Priority for directive parsing was reshuffled to ask extensions first and
check the generic directives later.
No change in functionality.
llvm-svn: 172568
simply use the getParser method from MCAsmParserExtension, working through the
MCAsmParser interface. There's no longer a need to overload that method to
cast it to the concrete AsmParser.
llvm-svn: 172491
This finally allows AsmParser to no longer list GenericAsmParser as a friend.
All member vars directly accessed by GenericAsmParser have been properly
encapsulated and exposed through the MCAsmParser interface. This reduces the
coupling between AsmParser and GenericAsmParser.
llvm-svn: 172490
Now that it behaves itself in terms of streamer independence (r172450), this
method can be moved to MCAsmParser to be available to all extensions,
overriding, etc.
-- -This line, and those below, will be ignored--
M lib/MC/MCParser/AsmParser.cpp
M include/llvm/MC/MCParser/MCAsmParser.h
llvm-svn: 172451
The aim of this patch is to fix the following piece of code in the
platform-independent AsmParser:
void AsmParser::CheckForValidSection() {
if (!ParsingInlineAsm && !getStreamer().getCurrentSection()) {
TokError("expected section directive before assembly directive");
Out.SwitchSection(Ctx.getMachOSection(
"__TEXT", "__text",
MCSectionMachO::S_ATTR_PURE_INSTRUCTIONS,
0, SectionKind::getText()));
}
}
This was added for the "-n" option of llvm-mc.
The proposed fix adds another virtual method to MCStreamer, called
InitToTextSection. Conceptually, it's similar to the existing
InitSections which initializes all common sections and switches to
text. The new method is implemented by each platform streamer in a way
that it sees fit. So AsmParser can now do this:
void AsmParser::CheckForValidSection() {
if (!ParsingInlineAsm && !getStreamer().getCurrentSection()) {
TokError("expected section directive before assembly directive");
Out.InitToTextSection();
}
}
Which is much more reasonable.
llvm-svn: 172450
Since it's used by extensions. One further step to fully decoupling
GenericAsmParser from an intimate knowledge of the internals of AsmParser,
pointing it to the MCASmParser interface instead (like all other parser
extensions do).
Since this change moves the MacroArgument type to the interface header, it's
renamed to be a bit more descriptive in a general context.
llvm-svn: 172449
The methods are also exposed via the MCAsmParser interface, which allows more
than one client to control them. Previously, GenericAsmParser was playing with
a member var in AsmParser directly (by virtue of being its friend).
llvm-svn: 172440
The MCAsmParser interface defines ParseIdentifier is public. There's no reason
whatsoever for AsmParser (which implements the MCAsmParser interface) to hide
this method.
This is all part of a bigger scheme. Several asm parsing "extensions" use the
main parser properly through the MCAsmParser interface. However,
GenericAsmParser has much more exclusive access and uses implementation details
from the concrete implementation - AsmParser, in which it is also declared as
a friend. This makes for overly coupled code, and even makes it hard to split
GenericAsmParser into a separate file. There's no reason why GenericAsmParser
shouldn't be able to access AsmParser through an abstract interface, as long
as it's actually registered as an extension.
llvm-svn: 172276
GenericAsmParser extension, where a lot of directives are already being parsed.
The end goal is having just a single place (and a single lookup table) for
all directive parsing.
llvm-svn: 172268
Dmitri Gribenko