<div dir="ltr">You have raised an interesting question here about model for decision-making, which unfortunately I don't think anyone really has an answer for. I certainly don't. <div><br></div><div>Anyways, yes, my response was indeed intended to be mostly-positive encouragement.</div><div><br></div><div>It seems to me that LLVM, as a project, generally encourages doing as much development in the upstream project as possible, while also being generally welcoming and helpful to closed-source downstream forks. That said, we cannot ignore the critical requirement that upstream developers continue to be able to make changes without having to remember all of the arbitrary untested/undocumented constraints closed-source downstream project may have.</div><div><br></div><div>That's why I like the formulation of this proposal as a "code clean-up", rather than a "feature". As a feature, it really cannot exist without a backend using it upstream, because we have no ability to test it, so it will be necessarily be broken. On the other hand, as a cleanup, it's entirely acceptable that only some of the code has abstracted away the number 8.</div><div><br></div><div>I'd suggest that this proposed cleanup should be allowed to happen -- but that upstream, we do NOT expose it as an overrideable value (e.g., don't put it in a target hook). Instead, make a non-overrideble function which always just returns 8. Document it as returning the number of bits in a character -- and that it's always 8 right now, but with the possibility that someday llvm may handle other bit-widths.</div><div><br></div><div>Any downstream users who wish to change the value now, will need to patch it to be a target hook (or whatever) in their fork -- and also fix anything that's not using the abstraction properly, because we don't actually support any other values upstream (due to no ability to test them).</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 14, 2019 at 7:09 AM Jesper Antonsson via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks to everyone that have weighed in on this! There have been<br>
remarks along the lines that the proposal lacks consensus to move<br>
forward, and that might very well be true. However, the decision model<br>
is not fully clear to me, so before giving up, I'd like to summarize<br>
the discussion to the best of my ability and ask for clarification on<br>
how the community makes its decisions.<br>
<br>
(First, I would like to emphasize that this is merely my<br>
interpretation, which may be flawed. If so, my apologies.) The RFC<br>
tl;dr is "without supporting non-8-bit bytes, we want to abstract the<br>
magic 8's used for bytesize to a DataLayout getter".<br>
<br>
It garnered some five supporters, including four companies representing<br>
out-of-tree backends: my own Ericsson, Synopsys, CML Microsystems and<br>
Codasip. I also count James Y Knight's (Google) remarks as positive.<br>
<br>
Two commenters I interpret as clearly against, among other things<br>
citing the need for a committment for an in-tree-backend using non-8-<br>
bit bytes to undertake such a change: JF Bastien and Philip Reames.<br>
<br>
Nine additional commenters provided side remarks to the discussion, and<br>
my interpretation was that five were in some small regard abstraction-<br>
positive as they provided input on the details of the abstraction,<br>
whereas two were more skeptical, and two were neither.<br>
<br>
<br>
Now to the decision model: If full consensus is required, we clearly<br>
don't have it, and we can stop here. However, if the abstraction were<br>
in place, we'd have a large majority against replacing them with 8s.<br>
And I guess it would be hard to move forward on very many things if<br>
everyone in a huge community can veto?<br>
<br>
Or should we take an insider-outsider perspective, then perhaps the<br>
opposers are in  majority as their in-tree voices are what counts?<br>
<br>
Or should we take a company perspective, then there's four companies<br>
backing this, while I'm unsure if e.g. JF is speaking for Apple?<br>
<br>
Or should we apply some reputation weights, so some people can veto?<br>
<br>
Or is it an informal mix of all of the above? I'm sorry if I'm being<br>
obnoxious, I really don't mean to. I'd just sleep better with clarity<br>
in closure, so that the discussion don't just fizzle out and I give up<br>
while having a sense that the community is leaning toward the positive<br>
on this.<br>
<br>
BR,<br>
Jesper<br>
<br>
<br>
On Thu, 2019-05-02 at 12:20 +0000, Jesper Antonsson via llvm-dev wrote:<br>
>    A. This RFC outlines a proposal regarding non-8-bit-byte support<br>
> that<br>
>       got positive reception at a Round Table at EuroLLVM19. The<br>
> general<br>
>       topic has been brought up several times before and one good<br>
> overview<br>
>       can be found in a FOSDEM 2017 presentation by Jones and Cook:<br>
> <br>
<a href="https://protect2.fireeye.com/url?k=0092ea36-5c19e105-0092aaad-865bb277df6a-f2acface76df5bb9&u=https://archive.fosdem.org/2017/schedule/event/llvm_16_bit/" rel="noreferrer" target="_blank">https://protect2.fireeye.com/url?k=0092ea36-5c19e105-0092aaad-865bb277df6a-f2acface76df5bb9&u=https://archive.fosdem.org/2017/schedule/event/llvm_16_bit/</a><br>
> <br>
> In a nutshell, the proposal is for the llvm community to<br>
> allow/encourage interested parties to gradually remove "magic<br>
> numbers",<br>
> e.g. assumptions on the size of bytes from the codebase. Overview,<br>
> rationale and some example refactorings follows.<br>
> <br>
> Overview:<br>
> <br>
> LLVM currently assumes 8-bit bytes, while there exist a few out-of-<br>
> tree <br>
> llvm targets that utilize bytes of other sizes, including our<br>
> (Ericsson's) proprietary target. The main issues are the magic number<br>
> 8<br>
> and "/8" and "*8" all over the place and the use of i8 pointers.<br>
> <br>
> There's considerable agreement that the use of magic numbers is not<br>
> good coding style, and removing these ones would be of particular<br>
> benefit, even though the effort would not be complete and no in-tree<br>
> target with tests exist to guarantee that all gains are maintained.<br>
> <br>
> Ericsson is willing to drive this effort. During EuroLLVM19, there<br>
> seemed to be sufficient positive interest from other companies for us<br>
> to expect help with reviewing patch sets. Ericsson has been<br>
> performing<br>
> nightly integration towards top-of-tree with this backend for years,<br>
> catching and fixing new 8-bit-byte continuously. Thus we're able to<br>
> commit to doing similar upstream fixes for the long haul in a no-<br>
> drama<br>
> way.<br>
> <br>
> Rationale:<br>
> <br>
> Benefits of moving toward a byte-size agnostic llvm include:<br>
> * Less magic numbers in the codebase.<br>
> * A reduced effort to maintain out-of-tree targets with non-8-bit<br>
> bytes<br>
> as contributors follow the established patterns. (One company has<br>
> told<br>
> us that they created but eventually gave up on a 16-bit byte target<br>
> due<br>
> to too-high integration burden.)<br>
> * A reduction in duplicate efforts as some of the adaptation work<br>
> would<br>
> happen in-tree rather than in several out-of-tree targets.<br>
> * For up-and-coming targets that have non-8-bit-byte sizes, time to<br>
> market using llvm would be far quicker.<br>
> * A higher probability of LLVM being the compiler of choice for such<br>
> targets.<br>
> * Eventually, as the patch set required to make llvm fully byte size<br>
> agnostic becomes small enough, the effort to provide a mock in-tree<br>
> target with some other byte size should be surmountable.<br>
> <br>
> As cons, one could see a burden for the in-tree community to maintain<br>
> whatever gains that have been had. However the onus should be on<br>
> interested parties to mend any bit-rot. The impact of not having as<br>
> much magic numbers and such should if anything make the code more<br>
> easy<br>
> to understand. The permission to go ahead would be under the<br>
> condition<br>
> that significant added complexities are avoided. Another con would be<br>
> added compilation time e.g. in cases where the byte size is a run-<br>
> time<br>
> variable rather than a constant. However, this cost seems negligible<br>
> in<br>
> practice.<br>
> <br>
> Refactoring examples:<br>
> <a href="https://reviews.llvm.org/D61432" rel="noreferrer" target="_blank">https://reviews.llvm.org/D61432</a><br>
> <br>
> Best Regards,<br>
> Jesper<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>