[LLVMdev] Add support for ldr pseudo instruction in ARM integrated assembler

[Sean Silva]

On Fri, Oct 25, 2013 at 4:11 PM, Renato Golin <renato.golin at linaro.org>wrote:

> On 25 October 2013 18:33, David Peixotto <dpeixott at codeaurora.org> wrote:
>
>> Both armasm and gnu as support an ldr pseudo instruction for loading
>> constants that lowers to either a mov, movn, or a pc-relative ldr from the
>> constant pool. It would be great if the llvm integrated assembler could
>> support this feature as well.
>>
>
> Hi David,
>
> 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.
>

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.



>
> Adding support for this GNU extension (that ARMCC also seem to support)
> can:
>
> 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.
>
> 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.
>
> 2. Increment the complexity of the assembler and disassembler in areas
> that you cannot predict right now.
>
> 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.
>
> 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.
>
> I may be wrong, correct me if I'm wrong, but as far as I got it, this
> looks just like syntactic sugar.
>

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

-- Sean Silva


>
> cheers,
> --renato
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131025/fa8f3eb4/attachment.html>