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

[Philip Reames via llvm-dev]

On 5/8/19 1:25 AM, Jesper Antonsson wrote:
> On Mon, 2019-05-06 at 15:56 -0700, Philip Reames via llvm-dev wrote:
>> On 5/6/19 2:43 AM, Tim Northover via llvm-dev wrote:
>>> On Mon, 6 May 2019 at 10:13, James Courtier-Dutton via llvm-dev
>>> <llvm-dev at lists.llvm.org> wrote:
>>>> Although the above is mentioning bytes, looking at the "/
>>>> 8"   and "& 0x7" makes it look like the author meant octets and
>>>> not bytes.
>>>> Bytes can be any size of bits.
>>> I don't think you'll have much luck trying to make that stick for a
>>> general audience, or even a general compiler-writer audience. Byte
>>> is
>>> far too strongly associated with 8 bits these days.
>> +1 Please don't try; insisting on a distinction will confuse many new
>> contributors.
> Yes, my interpretation is that the community is leaning toward
> addressable unit as terminology.
>
>>>> Octets are only ever 8 bits.
>>> You might be able to convert all uses of byte to octet and abandon
>>> byte entirely, but at that point why bother? It feels like a change
>>> just for the sake of pedantry.
>>>
>>> I like the "addressable unit" name, though it's a bit long
>>> (AddrUnit
>>> seems OK). It at least signals to a reader that there might be
>>> something weird going on. Getting someone writing new code to think
>>> in
>>> those terms is a different matter, of course, but I don't think any
>>> of
>>> the changes under discussion really help there.
>>>
>>> BTW, is there an open source backend (in a fork, I assume) that
>>> does
>>> this? So that we can get some kind of idea of the real scope of the
>>> changes needed.
>> Strongly agreed.
>>
>> My personal take is this is an invasive enough change with enough
>> likely
>> ongoing maintenance fall out to require substantial justification
>> before
>> the work was undertaken upstream.
> My hope and belief is that having good names instead of these magical
> numbers won't be a burden but rather an improvement long-term. 
>
>>   A open source backend proposed for
>> inclusion upstream would be one part of that.
> That is not on the table right now. However, as the work required to
> make such an inclusion happen will be reduced by this cleanup, the
> likelihood that it happens in the future should increase.
Given this, I'm not sure the community as a whole should take on the
burden of supporting non b-byte addressable units.  I see this as a
precondition.  To be clear, I don't care *which* backend there is,
doesn't have to be yours, but the presence of at least one would seem
necessary for testing if nothing else.
>
>>   Active contribution from
>> the sponsors in other areas would also be a key factor.
> I'm not sure how to interpret that, but our team here at Ericsson is
> fairly large, we have been working with this out-of-tree backend since
> 2011 and as a group, we contribute to upstream e.g. by helping out with
> the fixedpoint upstreaming, by solving and filing TRs (we're pretty
> good at testing I'd say), improving debug information and more.

Ok.

p.s. If my wording came across as implying any disrespect, sorry!  I was
making a general point, not thinking about how it might be read in
context. 

>
>>> Cheers.
>>>
>>> Tim.
>>> _______________________________________________
>>> 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