<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Oct 25, 2013 at 4:11 PM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="im">On 25 October 2013 18:33, David Peixotto <span dir="ltr"><<a href="mailto:dpeixott@codeaurora.org" target="_blank">dpeixott@codeaurora.org</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.<br></blockquote><div><br></div></div><div>Hi David,</div><div><br></div><div>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.</div>
</div></div></div></blockquote><div><br></div><div>FYI, Linux has at least 40 uses of this feature. And `git log --oneline --pickaxe-regex -S'ldr.*=' --since='1 year ago' arch/arm | wc -l` gives 55 uses. I'm not sure you can dismiss this as "support for old codebases". There are also at least 3 uses in x264 and >60 in ffmpeg. These were just the first 3 projects that I could think of that would have arm assembler in them; put another way, 3/3 projects that I sampled need this feature.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote">
<div><br></div><div>Adding support for this GNU extension (that ARMCC also seem to support) can:</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>2. Increment the complexity of the assembler and disassembler in areas that you cannot predict right now.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>I may be wrong, correct me if I'm wrong, but as far as I got it, this looks just like syntactic sugar.</div></div></div></div></blockquote><div><br></div><div>If the syntax sugar is part of the input format that users of the assembler expect, then I think it makes sense to support it. The concerns you have raised seem valid, but appear minor next to the reason for an assembler's existence: to assemble people's code (*not* its own test suite; that would be masturbatory). A person using the LLVM toolchain for its assembler doesn't care at all about those concerns, and just wants their code to work. A developer of one of the 3 projects I sampled would not be lying if they told their colleague: "I tried the LLVM toolchain for ARM, but the assembler is broken so I wasn't able to finish the build; I'll try again once the next version comes out and hopefully they will have fixed it by then".</div>
<div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>cheers,</div><div>--renato</div></div></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div></div>