llvm dev - Nov 2019 - RFC: On non 8-bit bytes and the target for it

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

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191101/b3f749e3/attachment.html>

On 11/1/19 5:41 AM, Dmitriy Borisenkov via llvm-dev 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.

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.


I also support option 1, although having an in-tree target would certainly be
better. That having been said, I'm assuming that the byte size will be part
of the DataLayout and, as a result, we can certainly have unit tests and tests
for IR-level changes in the usual way. We should only omit tests where we
can't currently have them.

 -Hal


--
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<mailto: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<mailto:llvm-dev at
lists.llvm.org>> wrote:
> >
> > > From: llvm-dev <llvm-dev-bounces at
lists.llvm.org<mailto: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<mailto: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<mailto: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<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191101/8ce2e8c1/attachment-0001.html>

> On Nov 1, 2019, at 3:41 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.
> 
> 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.
I'm in camp (2). Any changes that are not tested are an invitation to
upstream developers to "simplify" the code, not knowing that those
changes are important. Anyone who commits untested changes to LLVM will
inevitably face an uphill battle against benevolent NFC refactorings that break
these changes because the expectation of how the code is supposed to behave is
not codified in a test. In the short term option (1) sounds more appealing
because they can start right away, but I'm going to predict that it will be
more expensive for the downstream maintainers of non 8-bit targets in the long
term.

-- adrian

Did somebody say "PDP-10"?  😊
> 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.
Note that for the PDP-10, not all 5 criteria are the same thing.
It is a word-addressed machine (36-bit words) but the ISA has
instructions to handle 18-bit halfwords, and also defines a 
"byte pointer" to allow load/store of arbitrary-size bytes within 
a word.  Byte pointers allow any size byte that fits in a word 
(from 1 bit to 36 bits).  So what we have is:
> - The smallest unit that can be loaded / stored at a time.
This is 1 bit, from the ISA's perspective, using byte pointers.
Obviously caches and such would be word-based, but that's not
the point of this criterion.
> - The smallest unit that can be addressed with a raw pointer
    in a specific address space.

On PDP-10, the naïve interpretation of "raw pointer" would be
a simple memory address, so this is a 36-bit word.  (Halfword 
access uses different instructions to move the upper or lower 
halfwords; it's not encoded in the address.)
Note that `char *` is not a "raw pointer" in this sense; it is
a byte pointer.
> - The largest unit whose encoding is opaque to anything above
    the ISA.

I am not clear what this actually means.  I could interpret it
as a double-word floating point, but I doubt that was what was
intended.
> - The type used to represent `char` in C.
tl;dr: 7-bit byte.

C is hard to map to PDP-10. DEC did not provide a compiler,
although I was aware of a third-party C compiler; it used 7-bit 
ASCII for `char` which was the most typical character size on 
that machine.  (Sixbit was also used frequently, if you didn't
need lowercase or many special characters, e.g. for filenames.
8-bit ASCII was uncommon, unless you were forced into doing
data transfers to those newfangled PDP-11 and VAX things.)
This means that `char *` and `int *` had different formats, the
former being a byte pointer and the latter being an address;
casting was not free.
> - The type that has a size that all other types are a multiple
    of.

Discounting 'char' and strings, I'd have to say this would be
the 36-bit word, i.e. 'int'.

So, in summary, on the PDP-10 a "byte" might be any of:
- one bit
- seven bits
- 18 bits
- 36 bits
depending on what you mean.

Here endeth the lesson. 😊 Let me know if you need any other
historical trivia.

--paulr
DEC employee from 1982-1992

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>