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

Fri Nov 1 20:20:23 PDT 2019

On Fri, Nov 1, 2019 at 3:42 AM Dmitriy Borisenkov via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> A summary of the discussion so far.
>
> It seems that there are two possible solutions on how to move forward with
> non 8 bits byte:
>
> 1. Commit changes without tests. Chris Lattner, Mikael Holmen, Jeroen
> Dobbelaere, Jesper Antonsson support this idea.
> James Y Knight says that at least magic numbers should be removed "at
> least where it arguably helps code clarity". This might be not exactly the
> scope of the changes discussed, but it's probably worth do discuss code
> clarity having concrete patches.
> GCC (according to James Y Knight) has the same practice meaning non-8 bits
> byte is supported but there are no tests in upstream and we have downstream
> contributors who will fix the bugs if they appear in the LLVM core.
> David Chisnall raised a question about what to count as a byte (which
> defines the scope of the changes) and we suggest to use all 5 criteria he
> granted:
> > - The smallest unit that can be loaded / stored at a time.
> > - The smallest unit that can be addressed with a raw pointer in a
> specific address space.
> > - The largest unit whose encoding is opaque to anything above the ISA.
> > - The type used to represent `char` in C.
> > - The type that has a size that all other types are a multiple of.
> But if DSPs are less restrictive about byte, some of the criteria could be
> removed.
>
> 2. Use an iconic target. PDP10 was suggested as a candidate. This opinion
> found support from Tim Northover, Joerg Sonenberger, Mehdi AMINI, Philip
> Reames. It's not clear though does this opinion oppose upstreaming
> non-8-bits byte without tests or just a dummy and TVM targets options.
>

To clarify mine: I'm not in favor of 1. It seems to me like a "short term"
motivated approach that does not have a good testing/validation story, I'd
rather see a more complete proposal that have a path toward an end-to-end
solution.
Not that I am strongly opposed, but I see not going with 1 right now to put
the burden (or encourage) these downstream LLVM users to engage and create
(if this is critical enough) the complete upstream story instead of
stopping short there.

-- 
Mehdi

>
> So if there is no strong opposition to the solution 1 from the people
> supporting an iconic target option, we could probably move to the patches.
>
> --
> Kind regards, Dmitry Borisenkov
>
> On Thu, Oct 31, 2019 at 8:51 AM Mikael Holmén via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 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
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> 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/20191101/54e4683d/attachment.html>