Questions on ARMInstrInfo.td and MC/ARM/ELF

Hi Everyone,

I am trying to decide on a MC'ized reorg of ARMAsmPrinter for MC/ELF,
and had some questions.

Currently, it defines quite a few methods like printAddrMode4Operand
(linked to ARMInstrInfo.td) that currently assume raw text support in
the OutStreamer. Are these methods still supposed to be invoked in the
MC'ized path for assembly output?
Is JimG's new MC/.s ARMAsmPrinter::EmitInstruction() somehow bypassing
these completely?

and also on EmitStartOfAsmFile(), it emits a bunch of text assembly
attributes - which is clearly wrong for MC (but is still being used in
the asm emission).
Can anyone suggest a better mechanism to switch on this than using
OutStreamer.hasRawTextSupport()?

Thanks,

-Jason

Hi Everyone,

I am trying to decide on a MC'ized reorg of ARMAsmPrinter for MC/ELF,
and had some questions.

Currently, it defines quite a few methods like printAddrMode4Operand
(linked to ARMInstrInfo.td) that currently assume raw text support in
the OutStreamer. Are these methods still supposed to be invoked in the
MC'ized path for assembly output?
Is JimG's new MC/.s ARMAsmPrinter::EmitInstruction() somehow bypassing
these completely?

The ones in ARMAsmPrinter.cpp are now effectively unused, and I'll be removing them soon. I just need to do a bit of tablegen hacking first to be able to do so. The MC versions are in AsmPrinter/ARMInstPrinter.cpp.

and also on EmitStartOfAsmFile(), it emits a bunch of text assembly
attributes - which is clearly wrong for MC (but is still being used in
the asm emission).

Since this is by definition only for .s file emission, why is this clearly wrong? Perhaps it is, but it's not obvious to me why.

Jim, thanks for reply!

Hi Everyone,

I am trying to decide on a MC'ized reorg of ARMAsmPrinter for MC/ELF,
and had some questions.

Currently, it defines quite a few methods like printAddrMode4Operand
(linked to ARMInstrInfo.td) that currently assume raw text support in
the OutStreamer. Are these methods still supposed to be invoked in the
MC'ized path for assembly output?
Is JimG's new MC/.s ARMAsmPrinter::EmitInstruction() somehow bypassing
these completely?

The ones in ARMAsmPrinter.cpp are now effectively unused, and I'll be removing them soon. I just need to do a bit of tablegen hacking first to be able to do so. The MC versions are in AsmPrinter/ARMInstPrinter.cpp.

and also on EmitStartOfAsmFile(), it emits a bunch of text assembly
attributes - which is clearly wrong for MC (but is still being used in
the asm emission).

Since this is by definition only for .s file emission, why is this clearly wrong? Perhaps it is, but it's not obvious to me why.

Because EmitStartOfAsmFile() is being called regardless of the actual
MCStreamerModel() being used - at least for ARM and X86 (on X86, its
pretty much a no-op).

Since we're overloading calling AsmPrinter as an ObjFile printer as
well, I am uncertain as to what the "correct" case for MC is supposed
to be :slight_smile:

I want to understand the MC design intent a little bit better - Wish
there was a better way than to tease it apart from moving code tip....

Thanks again!

Hi Jim,

Since this is by definition only for .s file emission, why is this clearly wrong? Perhaps it is, but it's not obvious to me why.

Attributes should be emitted into object file as well...

Yes, but surely not by a function explicitly indicated to be for assembly files. I would expect there to be an equivalent function to do what needs done for object files. Perhaps there isn't one (yet) and that's what's leading to the confusion?

Hi Jim,

Since this is by definition only for .s file emission, why is this clearly wrong? Perhaps it is, but it's not obvious to me why.

Attributes should be emitted into object file as well...

Yes, but surely not by a function explicitly indicated to be for assembly files. I would expect there to be an equivalent function to do what needs done for object files. Perhaps there isn't one (yet) and that's what's leading to the confusion?

LOL :slight_smile: Yes, maybe that's it. Included is a patch w comments that
explains better.

Summation:

1. Should AsmPrinter::EmitStartOfAsmFile() be always called as is now?
2. If not, where should the arch-specific code go?
3. Where should the MCStreamer specific stuff for #2 go?

Again, these are all high level design intent questions. Perhaps Mr
Lattner can opine?

Thanks!

-jason

arm-mc-elf-s03-r115102.patch (1.16 KB)

Yes, but surely not by a function explicitly indicated to be for assembly files. I would expect there to be an equivalent function to do what needs done for object files. Perhaps there isn't one (yet) and that's what's leading to the confusion?

LOL :slight_smile: Yes, maybe that's it. Included is a patch w comments that
explains better.

Summation:

1. Should AsmPrinter::EmitStartOfAsmFile() be always called as is now?

Yes.

2. If not, where should the arch-specific code go?

N/A :slight_smile:

3. Where should the MCStreamer specific stuff for #2 go?

I'm not sure what you mean. The MCStreamer interface should have methods for all possible directives that can be sent to a .s file. The problem here has nothing to do with text output, it is that we don't have a way to send the ".syntax unified" directive down a streamer. The right fix is to add this support to MCStreamer.

-Chris

I'm not sure what you mean. The MCStreamer interface should have methods for all possible directives that can be sent to a .s file. The problem here has nothing to do with text output, it is that we don't have a way to send the ".syntax unified" directive down a streamer. The right fix is to add this support to MCStreamer.

Ahh! Okay. makes sense now. I'll send a small patch shortly.
Thanks

-jason