[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