[llvm-dev] 16-bit bytes for AsmPrinter/DWARF

Jesper Antonsson via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 24 02:54:27 PST 2017

That’s true. We have a number of other patches too: Some different helper functions, a target specific constant instead of the magic number 8 and so on.

Ideally, we’d like to upstream it all and would be fine with putting in the work required if the community is positive about it. As an out-of-tree target, we can’t supply tests that would ensure it keeps working, but we’d notice problems and continually upstream fixes.

Recently, we supplied most of our patches in this area to the DCPU16 project.


From: Eric Christopher [mailto:echristo at gmail.com]
Sent: den 23 januari 2017 23:43
To: Jesper Antonsson <jesper.antonsson at ericsson.com>; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] 16-bit bytes for AsmPrinter/DWARF

LLVM itself is pretty unfriendly to non 8-bit bytes - how are you solving this everywhere else?


On Fri, Jan 20, 2017 at 9:26 AM Jesper Antonsson via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

I’m with a team using 16-bit bytes for an out-of-tree target. The AsmPrinter framework’s implementation of the DWARF debugging format is not very good at distinguishing between target-sized bytes (which is the more common use) and 8-bit-bytes. The DWARF standard itself seems not very good in this regard, actually. So we have had to hack our way around this. I.e., at some call-sites of EmitSymbolValue(), EmitLabelDifference(), EmitIntValue() and EmitLabelReference(), an 8-bit-byte-sized argument has had to be converted to target-byte-size (which is extra hacky for odd numbers of eight-bit-bytes).

We’ve been thinking about what a good upstream fix would look like, and believe that perhaps converting all Size arguments in these call chains to BitSize would be the most practical way. The “cost” would be the multiplications necessary at call-sites. Would this be a good suggestion, and would anybody like to view and accept our patches for this?

LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170124/03e99495/attachment.html>

More information about the llvm-dev mailing list