[llvm-dev] [RFC] Refactor class hierarchy of VectorType in the IR (original) (raw)
John McCall via llvm-dev llvm-dev at lists.llvm.org
Fri May 22 18:31:09 PDT 2020
- Previous message: [llvm-dev] [RFC] Refactor class hierarchy of VectorType in the IR
- Next message: [llvm-dev] [RFC] Refactor class hierarchy of VectorType in the IR
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 22 May 2020, at 20:59, Chris Tetreault wrote:
John,
I’m not going to feel guilty about work you did for over a month without raising an RFC. I’m not sure what you mean by that, but I definitely did raise and RFC over this. On March 9th, I raised the initial RFC.
I did actually mention “when you raised the RFC in March” in this
email. But you’d said you’d started working on this in January, in
the context of talking about how much work you’d have to revisit. I
suppose you just meant that you started changing call sites over to
using getElementCount()
then; it does make sense that that’s still
work you’d have to revisit, although I think my suggestion of
temporarily deleting an “override” would substantially automate that
review.
I keep hearing that scalable vectors are experimental, and I don’t think that this is the case. The initial introduction of the type as a flag on VectorType was the experimental first step. Now we are taking the step where we consider how the initial step played out, and adapt with a well thought out solution.
This process that we’re engaged in right now is the community’s process of coming up with a well thought out solution. It’s happening now, rather than during your RFC, because in practice I don’t think most interested people have the time to actively read llvmdev; it’s common that only threads that already have a bit of traffic (like this one) will get broader attention. That is quite arguably a community process failure, but it’s nonetheless how it’s playing out.
I of course don’t speak for “the community”; none of us do individually. If the consensus is that we should do it your way, that’s fine; it’s certainly not the first or more invasive API change that LLVM has ever made. I do think Mehdi’s point is very important: when we talk about the rate of progress, we do need to consider the impact on downstream projects. You’ve spent maybe 40-50 workdays working on this, but I feel pretty confident that reacting to it downstream will cost substantially more time than that, no matter how mechanical the updates are, when summed across however many groups and companies are affected. That doesn’t mean it can’t be the right thing to do, of course. I just don’t think it is.
Anyhow, I’d be interested in hearing more people’s perspectives on it, and I’ll think about Eli’s post.
John. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200522/91ee0fc8/attachment.html>
- Previous message: [llvm-dev] [RFC] Refactor class hierarchy of VectorType in the IR
- Next message: [llvm-dev] [RFC] Refactor class hierarchy of VectorType in the IR
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]