[llvm-dev] Question about setting the dialect in AsmPrinterInlineAsm.cpp
Anirudh Prasad via llvm-dev
llvm-dev at lists.llvm.org
Thu Jan 7 12:50:12 PST 2021
Hi All,
Re-replying back to my question. The original message didn't seem to get a lot of traction when I posted it. I have posted a Phabricator patch here (https://reviews.llvm.org/D94250) which details a bit of what I spoke about in the original message (i.e. providing a custom overridden implementation in SystemZAsmParser.cpp to return the MAI's assembler dialect and provided a comment as to why it is problematic to query the overridden getAssemblerDialect function in AsmParser).
If there are any objections to this please do let me know. Alternatively, if there's a much nicer/cleaner way of going about it, please do let me know as well.
Thanks and Best Regards,
Anirudh Prasad
-----Anirudh Prasad/Canada/IBM wrote: -----
To: llvm-dev at lists.llvm.org
From: Anirudh Prasad/Canada/IBM
Date: 11/24/2020 03:58PM
Subject: Question about setting the dialect in AsmPrinterInlineAsm.cpp
Hi All,
While processing an inline asm block, within AsmPrinterInlineAsm.cpp, the inline asm dialect is forcibly set by the AsmParser instance (within the emitInlineAsm function)
void AsmPrinter::emitInlineAsm(StringRef Str, const MCSubtargetInfo &STI,
const MCTargetOptions &MCOptions,
const MDNode *LocMDNode,
InlineAsm::AsmDialect Dialect) const {
....
Parser->setAssemblerDialect(Dialect); // —> SETTING DIALECT HERE
Parser->setTargetParser(*TAP.get());
...
}
Because of setting the inline asm dialect in AsmPrinterInlineAsm.cpp, any queries to the overridden getAssemblerDialect method elsewhere, will return the set dialect, and not the assembler dialect in the MachineAsmInfo.
My question is, is this strictly necessary? EmitGCCInlineAsmStr and EmitMSInlineAsmStr is already set up to deal with gnu and intel inline asm flavours. Within the EmitMSInlineAsmStr, the .intel_syntax directive is also explicitly emitted. Couldn't we do away with setting the inline asm dialect in AsmPrinterInlineAsm.cpp (and subsequently change the overridden getAssemblerDialect method to just return the MCAsmInfo's version of the assembler dialect?) Are there any other use case(s) as to why it is being set?
Because otherwise, if we introduce another assembler dialect/variant, within the Target's respective MCAsmInfo instance (a variant which might be based off the standard two inline asm dialects), and we want to make use of it in the (Target)AsmParser, we would have to explicitly query the MCAsmInfo to get its version of the assembler dialect field (for any reasons we might need it). I'm not too "sure" if this is the correct way to go about it.
Thanks!
Best Regards,
Anirudh Prasad
More information about the llvm-dev
mailing list