[LLVMdev] AsmPrinter::EmitLinkage

[Nathan Jeffords]

On Mon, May 10, 2010 at 9:43 PM, Chris Lattner <clattner at apple.com> wrote:

>
> 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.
>
>
In the context I am looking at, it would be specific to the object file. I
was just pointing out that as it stands, it appears to only be responsible
for section assignment, and not any logic that would affect the AsmPrinter's
decision on what to emit. I don't know what the exact intent of this object
is other that the functionality it already implements, but it seems it would
make a good candidate to work with AsmPrinter (MCLower) to produce ouput for
a specific object file.


> > 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?
>
>
I think it emits valid output, but I don't think it handles weak symbols
correctly, as COFF supports true weak symbols, but this code appears to turn
them into a linkonce section which is not quite the same thing.

In my opinion, the body of this function should be different for each object
file type (at least for COFF). It could be handled in place as a large
if-then-else block, but when I see that type of code, which is the same in
the X86AsmPrinter::EmitEndOfAsmFile it seems to me that they should be
encapsulated somehow.

Perhaps, AsmPrinter itself could be specialized for the object file format
in use?


> >
>
> -Chris
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100511/208f57bf/attachment.html>