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

[Mikael Holmén via llvm-dev]

On Wed, 2019-10-30 at 15:30 -0700, Chris Lattner via llvm-dev wrote:
> > 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
> > > CHAR_BIT).
> > 
> > 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.

Thanks Chris! This is what we would like to see as well!

We have a 16bit byte target downstream and we live pretty much on top-
of-tree since we pull from llvm every day. Every now and then we find
new 8bit byte assumptions in the code that break things for us that we
fix downstream.

If we were allowed, we would be happy to upstream such fixes which
would make life easier both for us (as we would need to maintain fewer
downstream diffs) and (hopefully) for others living downstream with
other non-8bit byte targets.

Now, while we try to fix things in ways that would work for several
different byte sizes, what _we_ actually really test is 16bit bytes, so
I'm sure we fail to generalize things enough for all sizes, but at
least our contributions will make things more general than today. 

And I imagine that if other downstream targets use other byte sizes
than us they would also notice when things break and would also pitch
in and generalize it further so that it in the end works for all users.

/Mikael

> 
> -Chris
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> 
https://protect2.fireeye.com/v1/url?k=8c219edf-d0a845d0-8c21de44-0cc47ad93e1a-b9df048a1ecb44b1&q=1&e=95c12902-023a-4b29-913c-87a467fe82d9&u=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev