<div dir="ltr"><div dir="ltr"><strong>From: </strong>JF Bastien via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr"><strong>Date: </strong>Thu, May 9, 2019 at 1:30 PM<br><strong>To: </strong>Jesper Antonsson<br><strong>Cc: </strong><a href="mailto:dag@cray.com" target="_blank">dag@cray.com</a>, <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div>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 <i>someone</i> 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.</div></div></div></blockquote><div><br></div><div>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".</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div></div><div>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 <font face="Courier">8</font> 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 <font face="Courier">i8*</font> around, and how do you work around not having <font face="Courier">void*</font> in IR?</div></div></div></blockquote><div><br></div><div>This is a great list of questions that it would be good to have answers to, though.</div><div><br></div></div></div>