<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Book Antiqua";
panose-1:2 4 6 2 5 3 5 3 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Book Antiqua",serif;
color:#943634;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-IE link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'>I have experienced the exact same problem. The class ‘</span><span style='font-size:12.0pt;font-family:"Courier New";color:black;mso-fareast-language:EN-US'>MCAsmStreamer</span><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'>’ does almost everything we need for our custom assembler, but unfortunately this class is privately implemented totally within ‘</span><span style='font-size:12.0pt;font-family:"Courier New";color:black;mso-fareast-language:EN-US'>MCAsmStreamer.cpp</span><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'>’. Ideally this class would be advertised in a header because it is so immensely useful, and then custom assemblers such as yours and mine could simply specialise it with adaptations of the elements that differ.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'>A few years ago I did separate this into a header and an implementation file, but it proved too difficult to track the ongoing changes in the LLVM head sources and I gave up (one of the downsides of being out-of-tree). Now I have a few “hacks” to the implementation of ‘</span><span style='font-size:12.0pt;font-family:"Courier New";color:black;mso-fareast-language:EN-US'>MCAsmStreamer</span><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'>’ to adapt it to my needs which goes against the purity of interface versus implementation that I would prefer.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'>Writing my own pure custom streamer derived from ‘</span><span style='font-size:12.0pt;font-family:"Courier New";color:black;mso-fareast-language:EN-US'>MCStreamer</span><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'>’ was massive overkill when the existing ‘</span><span style='font-size:12.0pt;font-family:"Courier New";color:black;mso-fareast-language:EN-US'>MCAsmStreamer</span><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'>’ already did 98% of what I needed, and simply not worth the trouble versus using the hacks when tracking ongoing LLVM developments was also required. And because ‘</span><span style='font-size:12.0pt;font-family:"Courier New";color:black;mso-fareast-language:EN-US'>MCAsmStreamer</span><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'>’ is in an anonymous namespace in another file, I can’t even delegate to it.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'>Incrementally over the years, we have been altering our native assembler to be more conformant to the assembly language syntax supported by ‘</span><span style='font-size:12.0pt;font-family:"Courier New";color:black;mso-fareast-language:EN-US'>MCAsmStreamer</span><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'>’, but this always causes pain to our customers who have to alter their hand-written assembly files and inline assembly to match the breaking changes we make. But these changes have reduced our divergence from the ‘</span><span style='font-size:12.0pt;font-family:"Courier New";color:black;mso-fareast-language:EN-US'>MCAsmStreamer</span><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'>’ expectation from about 20 differences to just 5.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'>Now we have hacked implementations of ‘</span><span style='font-size:12.0pt;font-family:"Courier New";color:black;mso-fareast-language:EN-US'>EmitAssignment</span><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'>’, ‘</span><span style='font-size:12.0pt;font-family:"Courier New";color:black;mso-fareast-language:EN-US'>EmitBytes</span><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'>’, ‘</span><span style='font-size:12.0pt;font-family:"Courier New";color:black;mso-fareast-language:EN-US'>emitFill</span><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'>’ (inconsistent naming), ‘</span><span style='font-size:12.0pt;font-family:"Courier New";color:black;mso-fareast-language:EN-US'>EmitValueToAlignment</span><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'>’ (for exactly your point #4 - an unexpected breaking change made between LLVM v3.8 and v3.9) and ‘</span><span style='font-size:12.0pt;font-family:"Courier New";color:black;mso-fareast-language:EN-US'>EmitDwarfLocDirective</span><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'>’. In each case these are virtual functions, and a simple override rather than a hack would have been sufficient.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'>I would be very much in favour of promoting this very useful private class to 1<sup>st</sup> class citizen within the LLVM infrastructure, it would resolve the need for me to make target specific changes to the core implementation, and would also in great likelihood allow you and others to specialise just those elements that differ for your particular assembler dialect.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'>The class ‘</span><span style='font-size:12.0pt;font-family:"Courier New";color:black;mso-fareast-language:EN-US'>MCAsmInfo</span><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'>’ could also do with some enhancements, a very trivial one that was relevant to me a while ago, was the assumption that indentation should use a TAB rather than spaces (this impacted the assembly printer). I had to hack/adapt this too, though an extension to ‘</span><span style='font-size:12.0pt;font-family:"Courier New";color:black;mso-fareast-language:EN-US'>MCAsmInfo</span><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'>’ to allow the indentation separator to be provided by the target would be way better, especially for VLIW targets such as ours.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'> MartinO<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;color:#943634;mso-fareast-language:EN-US'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US>From:</span></b><span lang=EN-US> llvm-dev [mailto:llvm-dev-bounces@lists.llvm.org] <b>On Behalf Of </b>Davis, Alan via llvm-dev<br><b>Sent:</b> 26 April 2017 19:44<br><b>To:</b> llvm-dev@lists.llvm.org<br><b>Subject:</b> [llvm-dev] target-specific assembly printing<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=EN-US>I’m trying to retarget LLVM to a TI processor. We plan to use our existing assembler, which is not gas-based. I’m finding a lot of inconsistency in the retargeting hooks available under the AsmPrinter interface. I’ll cite four examples:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>1. The TI assembler’s global directive is called ‘.global’ rather than ‘.globl’. This one’s easy: there is a getGlobalDriective() interface in MCAsmInfo.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>2. The TI assembler’s common directive is called ‘.common’ rather than .comm’. Oops, that’s hardwired into MCAsmStreamer.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>3. The TI assembler’s common directive does not imply global linkage; a separate .global is required. I was able to hack that by overriding AsmPrinter::EmitGlobalVariable().<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>4. The TI assembler’s align directive is called ‘.align’ rather than ‘.p2align’ and its argument is absolute bytes, not a power of two. Oops, that’s also hardwired in.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>Those are a few of the things I’ve encountered so far; I’m sure there are dozens more. I’m wondering how to handle these types of things in general. I could:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>A) Keep extending MCAsmInfo for anything I need. This seems like it agrees with the intent of that interface, but I’m concerned it could be quite a few additions . I’m curious why it’s implemented as a bunch of scalar properties with getters rather than a general API. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>B) Override much of the default ASMPrinter in the target version. It seems like this could end up duplicating much of what is in the base class. Also much of the implementation is (currently) private, so the target version cannot access it. Of course, there is ‘protected’.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>C) Create a new implementation of the MCStreamer interface, similar to MCAsmStreamer, that would support the TI assembler. This seems overkill, as the formats are not that different. It also seems like it defeats the purpose of the MCAsmInfo interface.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>There are no plans to upstream any of this in the near future, but it could happen someday, so I’m looking for the most agreeable way forward. Thoughts?<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>-Alan<o:p></o:p></span></p></div></body></html>