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

[Jesper Antonsson via llvm-dev]

I agree, addressable unit size is probably a better abstraction.
However, in the lib/CodeGen directory alone, there's some 785 uses of
the word "byte" and a significant fraction of the code that we want to
modify is using the byte terminology today. An example of unmodified
code from my showcase patch set:

    assert(!(Shift & 0x7) == 0 &&
           "Shifts not aligned on Bytes are not supported.");
    uint64_t Offset = Shift / 8;
    unsigned TySizeInBytes = Origin->getValueSizeInBits(0) / 8;
    assert(!(Origin->getValueSizeInBits(0) & 0x7) == 0 &&
           "The size of the original loaded type is not a 
           "multiple of a byte.");

How would you prefer we handle this? If we only remove the magic
numbers using getAddressableUnitSize() instead of getBitsPerByte() we'd
get some mixed terminology. If the community is ok with that, we're
happy to do this. If we would go for changing the terminology overall,
then the work and the patch sizes would grow considerably.

BR,
Jesper


On Fri, 2019-05-03 at 20:17 +0000, Finkel, Hal J. via llvm-dev wrote:
> On 5/3/19 2:58 PM, llvm-dev wrote:
> > Jeroen Dobbelaere via llvm-dev <llvm-dev at lists.llvm.org> writes:
> > 
> > > Hi Jesper,
> > > 
> > > > Thanks, these are interesting differences. The CHAR_BIT and
> > > > byte
> > > > relation is established in the C standard and I would prefer
> > > > the byte
> > > > terminology. It means the same thing as addressable unit but is
> > > > a bit
> > > > shorter and probably more widely known.
> > > 
> > > Looking purely from a c/c++ language viewpoint, this makes
> > > sense.  We
> > > settled on using 'addressable unit size', but any abstraction
> > > will
> > > already be helpful.
> > 
> > Given that f18 has just been accepted as an LLVM project, we
> > probably
> > shouldn't be using C/C++ or any specific language terminology in
> > LLVM.
> 
> Regardless of f18, we shouldn't anyway, unless it's terminology we
> independently define in our language reference. LLVM has supported
> many different language frontends for a long time :-)
>  -Hal
> 
> > It seems useful to distinguish "addressable unit size" from "data
> > size"
> > and talk about things using such abstract terminology.
> > 
> >                             -David
> > _______________________________________________
> > 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