[LLVMdev] AsmPrinter::EmitLinkage

[Chris Lattner]

On May 10, 2010, at 6:46 PM, Nathan Jeffords wrote:

> I have been looking over AsmPrinter::EmitLinkage (around line 195 of lib\CodeGen\AsmPrinter\AsmPrinter.cpp)  and it seems that its implementation will vary quite a bit depending on what object file format is in use (MachO, ELF, or COFF).
> Would it make sense to delegate the implementation to a specialized object from current the object file format?

Why?  It is AsmPrinter's job to handle the lowering of MachineInstrs and LLVM IR (for globals etc) to the MC level primitives.  AsmPrinter should really be renamed MCLowering at some point.

> I am tempted to make it the MCAsmInfo implementation for the specific target. Currently MCAsmInfo looks just to hold useful information about the target, and not any target specific code.

Right. MCAsmInfo has been designed to be filled in by targets but not subclassed.  This implies that it can't have virtual methods.

> TargetLoweringObjectFile looks to perform a similar function as MCAsmInfo, though this doesn't look to be responsible for directing the AsmPrinter, its only responsibility appears to be providing section assignment logic.

TLOF is designed to be specific to the object file, but ideally not target specific. This means we should have TLOFMacho but not TLOFX86Macho.

> Another candidate I considered what TargetAsmBackend, but that appears to be meant to sit behind MCStreamer.

Right, that is the actual implementation of the object writer for a specific target.

> Another approach would be to further subdivide X86AsmPrinter to have object file format specific variants that could implement the required logic. The problems I am trying to solve are processor independent so I don't think this would be the right approach, but it could potentially be useful in other situations.
> 
> Finally, a new object could be created that is specialized by the different object file formats. There are already a number of specialized objects, and seems like at would make things confusing.
> 
> I think there are other places that could benefit from a similar transformation. On example would be the handling of the X86AsmPrinter::EmitEndOfAsmFile which has three separate blocks of code dedicated to the different object file formats. At least in the case of COFF, the operations being performed are not specific to X86.


What problem are you trying to solve here?  I'm pretty sure that AsmPrinter is emitting valid COFF output already, no?

> 

-Chris