Question about setting the assembler 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.

void AsmPrinter::emitInlineAsm(StringRef Str, const MCSubtargetInfo &STI,

const MCTargetOptions &MCOptions,

const MDNode *LocMDNode,

InlineAsm::AsmDialect Dialect) const {


if (!TAP)

report_fatal_error("Inline asm not supported by this streamer because"

" we don't have an asm parser for this target\n");

Parser->setAssemblerDialect(Dialect); // —> SETTING DIALECT HERE


// Enable lexing Masm binary and hex integer literals in intel inline

// assembly.

if (Dialect == InlineAsm::AD_Intel)




The overridden getAssemblerDialect method in AsmParser.cpp is set up as follows.

unsigned getAssemblerDialect() override {

if (AssemblerDialect == ~0U)

return MAI.getAssemblerDialect();


return AssemblerDialect;


Because of setting the inline asm dialect in AsmPrinterInlineAsm.cpp, any queries to the overridden getAssemblerDialect() method elsewhere, will return the set inline assembler dialect in AsmParser, and not the assembler dialect field in the MachineAsmInfo.

My question is, is this strictly necessary? EmitGCCInlineAsmStr and EmitMSInlineAsmStr is already set up to deal with GNU asm and Intel asm flavours, and within the EmitMSInlineAsmStr function, the .intel_syntax directive is explicitly emitted. Couldn’t we do away with setting the dialect in AsmPrinterInlineAsm.cpp? (and subsequently change the overridden function to just return the AssemblerDialect field of the MachineAsmInfo instance). Are there other case(s) as to why we’re setting it?

Because otherwise, if we introduce another assembler dialect/variant within the respective MCAsmInfo instance (that might be based off the standard two inline asm dialects from the frontend), and we want to make use of it in the backend (Target)AsmParser, we would have to explicitly query MCAsmInfo to get the dialect (for any reasons) and not the dialect set in the Parser. I’m not too sure if this is “correct” to do or if there’s another way of going about it.


Best Regards,

Anirudh Prasad