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

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Tue Oct 29 18:18:26 PDT 2019

On 10/29/19 5:13 PM, JF Bastien via llvm-dev wrote:
>> On Oct 29, 2019, at 3:39 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> On Tue, Oct 29, 2019 at 07:19:25PM +0000, Tim Northover via llvm-dev 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.
>> PDP10 is iconic enough?
> Is it relevant to any modern compiler though?
> I strongly agree with Tim. As I said in previous threads, unless people will have actual testable targets for this type of thing, I think we shouldn’t add maintenance burden.

Strongly agreed here as well.

>   This isn’t really C or C++ anymore because so much code assumes CHAR_BIT == 8, or at a minimum CHAR_BIT % 8 == 0, that we’re supporting a different language. IMO they should use a different language, and C / C++ should only allow CHAR_BIT % 8 == 0 (and only for small values of CHAR_BIT).

More information about the llvm-dev mailing list