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

[James Y Knight via llvm-dev]

*From: *JF Bastien via llvm-dev <llvm-dev at lists.llvm.org>
*Date: *Thu, May 9, 2019 at 1:30 PM
*To: *Jesper Antonsson
*Cc: *dag at cray.com, llvm-dev at lists.llvm.org

I don’t think you have consensus to move forward at this point in time. My
> expectation, which I think represents LLVM’s historical approach, is that a
> path to full support be planned out before this effort starts. Concretely,
> I expect a real-world backend to be committed to LLVM as a necessary step.
> What I meant upthread was: yes it makes sense to do cleanups before landing
> a backend, but *someone* has to commit to upstreaming a backend before
> you start the cleanups. When I say a backend I don’t mean a toy, I mean a
> real backend.
>

IMO, the argument of removing "magic constants", and replacing them with a
semantically meaningful value does have some merit, even lacking any
backend that uses a number other than "8".

I guess I'd say that my feeling is that if llvm's codebase already had a
"bitsPerUnit()" accessor (as GCC calls this concept), I would probably not
say that we should replace all the calls with literal '8's across the
code-base simply because no current target uses any value other than 8.
It's an abstraction which does make sense on its own, even if it's
currently always 8.

So, I'm somewhat agnostic here -- the change itself has little value
upstream, but if the state of the codebase afterwards is not degraded by
the change (and on the contrary, can be ever-so-marginally improved), that
seems like it could be basically okay.

Right now we have no commitment on anybody landing a backend, and we don’t
> really have a concrete idea of what you’re even proposing to change or how.
> You’re focusing on “magic numbers” like everyone agrees 8 is the root of
> all evil, and it’s really not. Let’s say someone promises to upstream a
> backend, what concretely do you need to change, and in which projects, to
> get there? Are you changing clang, and how? What about libc++? Linker?
> LLVM, and how? Is IR going to change? If not, do you keep all the i8*
> around, and how do you work around not having void* in IR?
>

This is a great list of questions that it would be good to have answers to,
though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190509/e3e635c5/attachment.html>