[LLVMdev] Calling-convention lowering proposal
David Greene
dag at cray.com
Thu Apr 30 09:35:11 PDT 2009
On Wednesday 29 April 2009 17:01, Tanya M. Lattner wrote:
> > I completely agree with the goals of this patch. However, I would ask
> > that we deprecate the existing interfaces for 2.6 and then remove them in
> > 2.7. We should add the new interfaces under a different name until 2.7
> > at which point they will become default.
>
> I don't really see how this is any different. Instead of changing the API
> in 2.6, it just gets postponed to 2.7. So with 2.7 you have to upgrade
> your API and track down new bugs introduced by 2.7 (hopefully not very
> many).
The difference is that it isolates the API change from the other changes in
LLVM.
When we do an upgrade to a new LLVM release, we spend a significant amount
of time resolving conflicts and fixing new bugs. It's one less thing to have
to worry about if APIs remain stable (through deprecation).
What we would do is fix all of the bugs, etc. then afterward move our code
over to the new APIs. Then for the next release it's simply a matter of
renaming the API function we call.
> The majority of the people are not going to make the API changes until
> they are forced to. Its just low on the priority list. We've seen this
> from many people who don't upgrade because they don't want to make the API
> changes.
But you have to give people warning. That's what deprecation does. It means
people can upgrade and fix all of the resulting problems without having to
worry about changing APIs at the same time. They can then migrate to the new
API before upgrading to the next version that removes the deprecated API.
Deprecation doesn't solve the "people not wanting to upgrade" problem. That's
not the point. There's very little we can do to satisfy those people. What
deprecation does is help the people that DO want to upgrade to the new
API but would prefer an incremental way of doing it.
We talk about making incremental changes to the LLVM repository all the time.
Why would we not apply the same philosophy to releases?
Every open source project with a significant client base does things this way.
I believe LLVM has reached this point as well.
-Dave
More information about the llvm-dev
mailing list