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

Chris Lattner via llvm-dev llvm-dev at lists.llvm.org
Wed Oct 30 15:30:38 PDT 2019

> On Oct 30, 2019, at 3:07 AM, Jeroen Dobbelaere via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of JF Bastien via
> [..]
>> 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. 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
> We (Synopsys ASIP Designer team) and our customers tend to disagree: our customers do create plenty of cpu architectures
> with non-8-bit characters (and non-8-bit addressable memories). We are able to provide them with a working c/c++ compiler solution.
> Maybe some support libraries are not supported out of the box, but for these kind of architectures that is acceptable. 
> (Besides that, llvm is also more than just c/c++)

I agree - there are a lot of weird accelerators with LLVM backends, many of them aren’t targeted by C compilers/code.  The ones that do have C frontends often use weird dialects or lots of builtins, but they are still useful to support.

I find this thread to be a bit confusing: it seems that people are aware that such chips exists (even today) but some folks are reticent to add generic support for them.  While I can see the concern about inventing new backends just for testing, I don’t see an argument against generalizing the core and leaving it untested (in master).  If any bugs creep in, then people with downstream targets can fix them in core.


More information about the llvm-dev mailing list