[llvm-dev] RFC: On non 8-bit bytes and the target for it

[James Y Knight via llvm-dev]

I'd note that GCC removed its last upstream target with a BITS_PER_UNIT !=
8 in version 4.3 in 2008 (that was TMS320C3x/C4x), and there have been none
added since. AFAIK, they're in option #1 mode -- no testing upstream, but
maybe with downstream forks that still use the ability to set it to other
values, and besides, a constant is nicer than a magic "8" anyways.

Last time this was discussed, the LLVM project already came to a consensus
that it's reasonable to remove magic "8"s from the code, at least where it
arguably helps code clarity -- and if that helps downstream forks with
weird byte-sizes too, that's wonderful.

But, it's not at all clear to me that it's at all worthwhile to do more
than that (e.g. changing core stuff like datalayout, introducing weird and
otherwise-irrelevant targets, or trying to figure out how to test the
functionality for changing the byte-width without a target).


On Tue, Oct 29, 2019 at 3:19 PM Tim Northover via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Tue, 29 Oct 2019 at 19:11, Dmitriy Borisenkov via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > 2. Test with a dummy target. It might work if we have a group of
> contributors who is willing to rewrite and upstream some of their
> downstream tests as well as to design and implement the target itself. The
> issue here might be in functional tests, so we'd probably need to implement
> a dummy virtual machine to run them because lit tests are unlikely to catch
> all issues from paragraphs (2) and (3) of the scope described.
> > 3. TON labs can provide its crazy target or some lightweight version of
> it. From the testing point of view, it works similar to the second
> solution, but it doesn't require any inventions. I could create a separate
> RFC about the target to find out if the community thinks it's appropriate.
>
> I'm not great at history, are there any historically iconic targets
> that aren't 8-bit but are otherwise sane? I'd prefer to spend the
> project's resources supporting something like that than either an
> invented target or a speculative crypto-currency oddity.
>
> Cheers.
>
> Tim.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191029/19d11527/attachment.html>