<br><br><div class="gmail_quote">On Mon, May 10, 2010 at 9:43 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On May 10, 2010, at 6:46 PM, Nathan Jeffords wrote:<br>
<br>
> 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).<br>

> Would it make sense to delegate the implementation to a specialized object from current the object file format?<br>
<br>
</div>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.<br>
<div class="im"><br>
> 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.<br>
<br>
</div>Right. MCAsmInfo has been designed to be filled in by targets but not subclassed.  This implies that it can't have virtual methods.<br>
<div class="im"><br>
> 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.<br>

<br>
</div>TLOF is designed to be specific to the object file, but ideally not target specific. This means we should have TLOFMacho but not TLOFX86Macho.<br>
<div class="im"><br></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> Another candidate I considered what TargetAsmBackend, but that appears to be meant to sit behind MCStreamer.<br>
<br>
</div>Right, that is the actual implementation of the object writer for a specific target.<br>
<div class="im"><br>
> 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.<br>

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

<br>
<br>
</div>What problem are you trying to solve here?  I'm pretty sure that AsmPrinter is emitting valid COFF output already, no?<br>
<br></blockquote><div><br></div><div>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.</div>
<div><br></div>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.<div>
<br></div><div>Perhaps, AsmPrinter itself could be specialized for the object file format in use?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
><br>
<font color="#888888"><br>
-Chris<br>
<br>
</font></blockquote></div><div><br></div>