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