[llvm-dev] target-specific assembly printing

[Davis, Alan via llvm-dev]

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:
1. The TI assembler's global directive is called '.global' rather than '.globl'. This one's easy: there is a getGlobalDriective() interface in MCAsmInfo.
2. The TI assembler's common directive is called '.common' rather than .comm'. Oops, that's hardwired into MCAsmStreamer.
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().
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.
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:
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.
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'.
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.
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?

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170426/2b136b52/attachment.html>