<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=iso-8859-1"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","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;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
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-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi Renato, Thanks for the thoughtful reply. Please find my thoughts below.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-- </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Renato Golin [mailto:renato.golin@linaro.org] <br><b>Sent:</b> Friday, October 25, 2013 1:11 PM<br><b>To:</b> David Peixotto<br><b>Cc:</b> LLVM Dev; Logan Chien; Gabor Ballabas; Rafael Espíndola; Richard Barton; Amara Emerson<br><b>Subject:</b> Re: Add support for ldr pseudo instruction in ARM integrated assembler<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On 25 October 2013 18:33, David Peixotto <<a href="mailto:dpeixott@codeaurora.org" target="_blank">dpeixott@codeaurora.org</a>> wrote:<o:p></o:p></p><div><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal>Both armasm and gnu as support an ldr pseudo instruction for loading<br>constants that lowers to either a mov, movn, or a pc-relative ldr from the<br>constant pool. It would be great if the llvm integrated assembler could<br>support this feature as well.<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Hi David,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>As much as I think that it's important to add support for old codebases to be compiled, I also have to consider the importance of compatibility and compiler sanity.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Adding support for this GNU extension (that ARMCC also seem to support) can:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>1. Add multiple representations to the same operation, which is fine when you're converting ASM into binary, but not so much when you're doing the reverse.<o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>By the reverse, do you mean converting binary to asm? If so I do not think there would be an issue here because we would never need to generate the ldr pseudo instruction. It is really a convenience for the programmer much like macros. Once it has been converted to mov/ldr+constant pool there would be no need to go the opposite direction. I think it is similar to macros in that regard in that we do not need to reconstruct the macro after it has been processed by the assembler to generate the final output.<o:p></o:p></span></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>We have been trying to deprecate pre-UAL and GNU-extensions as much as possible, and this is a move that is supported from most of the ARM LLVM community. The main reason is, as I said, to be able to come to and from ASM, having the same canonical representation. This will make it a lot easier to test the compiler and to avoid silent asm/disasm failures not covered by the tests. We also have been avoiding to remove pre-UAL support just because "bacon", but if it impacts a needed change, or if removing it fixes a bug, we tend to trim it off.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>2. Increment the complexity of the assembler and disassembler in areas that you cannot predict right now.<o:p></o:p></p></div><div><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Yes, I was wondering about this part. I’m not familiar with whether the assembler can easily create constant pools which is something that would definitely be needed.  From my first glance it looks like creating and placing the constant pool is the tricky part in actually implementing this feature.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p></div><div><p class=MsoNormal>It seems that this syntax allows for you to define symbols and constant pools, and both have interactions with the rest of the code generation, relocation symbols, etc. I can't guarantee right now that there will be no conflicts with anything elsewhere, and to make sure we're covering all bases, a huge amount of tests will need to be added. Of course, people are free to work on things that make their work compile and run, but you have to be aware that GNU-extensions and pre-UAL features are not taken lightly.<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Ultimately, if there is a feature that cannot be done any other way in ARM UAL, than we shall consider the options and implement the best. But if this is just syntactic sugar, than I'd strongly suggest you to upgrade your assembly files. The argument that "GCC does it" is used far too often in the LLVM list, and I can't say I'm a big fan of it. GCC did not take *only* smart decisions in its life (neither did LLVM), and copying everything from one side to the other blindly is not a good strategy.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I may be wrong, correct me if I'm wrong, but as far as I got it, this looks just like syntactic sugar.<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I cannot think of why it would be more than syntactic sugar at this point. For me it is a new feature that I encountered when trying to compile some of our code bases here so it is possible that there could be something more that I’m missing. That said, I do think it is a useful sugar when you actually have to write assembly.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I think probably it is blindly convert each instance like this:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>    ldr r0, =foo<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>    @continuation point<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>==><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>    ldr r0, [pc]<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>    b 2f<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>1:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>    .word foo<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>2:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>   @continuation point<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I think the first is much easier for the programmer to write and maintain. Btw, the local numeric label syntax (1:, b 1f) was new to me as well. Luckily for me the integrated assembler already supports this syntax :)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p></div><div><p class=MsoNormal>cheers,<o:p></o:p></p></div><div><p class=MsoNormal>--renato<o:p></o:p></p></div></div></div></div></div></div></body></html>