[llvm-dev] RFC: On removing magic numbers assuming 8-bit bytes

Wed May 29 04:41:32 PDT 2019

Philip, thank you for your eludication. The loose consensus model that
you outline probably works well in most cases. It does seem to favor
status quo while disfavoring newcomers so I imagine a number of useful
efforts will be left by the wayside and this to suppress community
growth somewhat. OTOH, it's easy to see advantages and there are
perhaps no better decison models or tradeoffs to be had.

Thanks again,
Jesper

On Tue, 2019-05-28 at 11:20 -0700, Philip Reames wrote:
> Jesper, on the abstract decision model side of things, let me share
> my
> understanding.  Note that I'm specifically not speaking for the
> project
> as a whole, just the way I think about things.
> 
> In practice, we generally use a loose consensus model.  We don't
> require
> full consensus, but we do require there to be a) an agreement on
> direction being generally valuable to more than the contributor, b) a
> lack of strong objections from established contributors, and c) an
> (often implicit) commitment from the proposer to invest enough effort
> in
> the project to justify any downsides other contributors might
> experience. 
> 
> Point (c) is frequently where a lot of large proposals from new
> contributors fail.  Unless there's someone else strongly motivated to
> drive it forward who can step in to satisfy (c), then a proposal is
> likely to die on the vine.   Some of the most important feedback any
> proposal gets is about how to reduce the cost to other contributors. 
> If
> that feedback is ignored, then the proposal is almost certain dead. 
> (I
> see this all the time.)
> 
> Point (b) is a major stumbling block, but can almost always be worked
> through.  There's a couple of implicit points worth noting.  1) We
> require that objections be largely technical in nature.  2) Anyone
> objecting strongly is expect to be themselves a long term contributor
> whose been through the process before. 3) There's a lot of horse
> trading
> which goes on behind the scenes, and 4) because a strong objection is
> so
> powerful, it's frequently waived.  Objections based on (1) can
> frequently be addressed through offline direct conversation, and
> frequently lead to revisions in proposal.  (Usually, a reduction in
> initial scope, sometimes the opposite.)  (3) is a practical necessity
> as
> no one has the time to review and think through *everything*; I'm
> much
> more likely to invest time in a proposal coming from someone who I've
> worked closely with in the past than a stranger.  (4) shows up in
> subtle
> ways.  If you've seen me or someone else say something to the effect
> of
> "Drive by comment", "minor concern", "deferring to X on point Y",
> those
> are all indications that I've chosen explicitly *not* to express a
> strong objection.
> 
> Point (a) may seem like the core point, but it's generally the
> easiest. 
> Once (b) has been addressed, (a) almost always follows. 
> 
> Again, speaking only for myself. 
> 
> Philip
> 
> 
> On 5/14/19 4:08 AM, Jesper Antonsson via llvm-dev wrote:
> > Thanks to everyone that have weighed in on this! There have been
> > remarks along the lines that the proposal lacks consensus to move
> > forward, and that might very well be true. However, the decision
> > model
> > is not fully clear to me, so before giving up, I'd like to
> > summarize
> > the discussion to the best of my ability and ask for clarification
> > on
> > how the community makes its decisions.
> > 
> > (First, I would like to emphasize that this is merely my
> > interpretation, which may be flawed. If so, my apologies.) The RFC
> > tl;dr is "without supporting non-8-bit bytes, we want to abstract
> > the
> > magic 8's used for bytesize to a DataLayout getter".
> > 
> > It garnered some five supporters, including four companies
> > representing
> > out-of-tree backends: my own Ericsson, Synopsys, CML Microsystems
> > and
> > Codasip. I also count James Y Knight's (Google) remarks as
> > positive.
> > 
> > Two commenters I interpret as clearly against, among other things
> > citing the need for a committment for an in-tree-backend using non-
> > 8-
> > bit bytes to undertake such a change: JF Bastien and Philip Reames.
> > 
> > Nine additional commenters provided side remarks to the discussion,
> > and
> > my interpretation was that five were in some small regard
> > abstraction-
> > positive as they provided input on the details of the abstraction,
> > whereas two were more skeptical, and two were neither.
> > 
> > 
> > Now to the decision model: If full consensus is required, we
> > clearly
> > don't have it, and we can stop here. However, if the abstraction
> > were
> > in place, we'd have a large majority against replacing them with
> > 8s.
> > And I guess it would be hard to move forward on very many things if
> > everyone in a huge community can veto?
> > 
> > Or should we take an insider-outsider perspective, then perhaps the
> > opposers are in  majority as their in-tree voices are what counts?
> > 
> > Or should we take a company perspective, then there's four
> > companies
> > backing this, while I'm unsure if e.g. JF is speaking for Apple?
> > 
> > Or should we apply some reputation weights, so some people can
> > veto?
> > 
> > Or is it an informal mix of all of the above? I'm sorry if I'm
> > being
> > obnoxious, I really don't mean to. I'd just sleep better with
> > clarity
> > in closure, so that the discussion don't just fizzle out and I give
> > up
> > while having a sense that the community is leaning toward the
> > positive
> > on this.
> > 
> > BR,
> > Jesper
> > 
> > 
> > On Thu, 2019-05-02 at 12:20 +0000, Jesper Antonsson via llvm-dev
> > wrote:
> > >    A. This RFC outlines a proposal regarding non-8-bit-byte
> > > support
> > > that
> > >       got positive reception at a Round Table at EuroLLVM19. The
> > > general
> > >       topic has been brought up several times before and one good
> > > overview
> > >       can be found in a FOSDEM 2017 presentation by Jones and
> > > Cook:
> > > 
> > 
> > 
https://protect2.fireeye.com/url?k=0092ea36-5c19e105-0092aaad-865bb277df6a-f2acface76df5bb9&u=https://archive.fosdem.org/2017/schedule/event/llvm_16_bit/
> > > In a nutshell, the proposal is for the llvm community to
> > > allow/encourage interested parties to gradually remove "magic
> > > numbers",
> > > e.g. assumptions on the size of bytes from the codebase.
> > > Overview,
> > > rationale and some example refactorings follows.
> > > 
> > > Overview:
> > > 
> > > LLVM currently assumes 8-bit bytes, while there exist a few out-
> > > of-
> > > tree 
> > > llvm targets that utilize bytes of other sizes, including our
> > > (Ericsson's) proprietary target. The main issues are the magic
> > > number
> > > 8
> > > and "/8" and "*8" all over the place and the use of i8 pointers.
> > > 
> > > There's considerable agreement that the use of magic numbers is
> > > not
> > > good coding style, and removing these ones would be of particular
> > > benefit, even though the effort would not be complete and no in-
> > > tree
> > > target with tests exist to guarantee that all gains are
> > > maintained.
> > > 
> > > Ericsson is willing to drive this effort. During EuroLLVM19,
> > > there
> > > seemed to be sufficient positive interest from other companies
> > > for us
> > > to expect help with reviewing patch sets. Ericsson has been
> > > performing
> > > nightly integration towards top-of-tree with this backend for
> > > years,
> > > catching and fixing new 8-bit-byte continuously. Thus we're able
> > > to
> > > commit to doing similar upstream fixes for the long haul in a no-
> > > drama
> > > way.
> > > 
> > > Rationale:
> > > 
> > > Benefits of moving toward a byte-size agnostic llvm include:
> > > * Less magic numbers in the codebase.
> > > * A reduced effort to maintain out-of-tree targets with non-8-bit
> > > bytes
> > > as contributors follow the established patterns. (One company has
> > > told
> > > us that they created but eventually gave up on a 16-bit byte
> > > target
> > > due
> > > to too-high integration burden.)
> > > * A reduction in duplicate efforts as some of the adaptation work
> > > would
> > > happen in-tree rather than in several out-of-tree targets.
> > > * For up-and-coming targets that have non-8-bit-byte sizes, time
> > > to
> > > market using llvm would be far quicker.
> > > * A higher probability of LLVM being the compiler of choice for
> > > such
> > > targets.
> > > * Eventually, as the patch set required to make llvm fully byte
> > > size
> > > agnostic becomes small enough, the effort to provide a mock in-
> > > tree
> > > target with some other byte size should be surmountable.
> > > 
> > > As cons, one could see a burden for the in-tree community to
> > > maintain
> > > whatever gains that have been had. However the onus should be on
> > > interested parties to mend any bit-rot. The impact of not having
> > > as
> > > much magic numbers and such should if anything make the code more
> > > easy
> > > to understand. The permission to go ahead would be under the
> > > condition
> > > that significant added complexities are avoided. Another con
> > > would be
> > > added compilation time e.g. in cases where the byte size is a
> > > run-
> > > time
> > > variable rather than a constant. However, this cost seems
> > > negligible
> > > in
> > > practice.
> > > 
> > > Refactoring examples:
> > > https://reviews.llvm.org/D61432
> > > 
> > > Best Regards,
> > > Jesper
> > > _______________________________________________
> > > 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