llvm dev - Sep 2010 - [LLVMdev] 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

On Sep 29, 2010, at 3:09 PM, Jason Kim wrote:
> 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.
> Can anyone suggest a better mechanism to switch on this than using
> OutStreamer.hasRawTextSupport()?
> 
> Thanks,
> 
> -Jason

Jim, thanks for reply!

On Wed, Sep 29, 2010 at 3:15 PM, Jim Grosbach <grosbach at apple.com>
wrote:
>
> On Sep 29, 2010, at 3:09 PM, Jason Kim wrote:
>
>> 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 :)

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!
>> Can anyone suggest a better mechanism to switch on this than using
>> OutStreamer.hasRawTextSupport()?
>>
>> Thanks,
>>
>> -Jason
>
>

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...

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University