Anirudh Prasad via llvm-dev
2021-Jan-07 20:50 UTC
[llvm-dev] Question about setting the dialect in AsmPrinterInlineAsm.cpp
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