vaargs and backwards compatibility

So Alpha and some other potential targets (amd64?) use structs for
va_list. This is very much at odds with the current instructions and
intrinsics.

So the question for the community is how much backwards compatibility
should be maintained for vaargs? Essentially the behavior needs to be
reverted to LLVM 1.0 semantics for vaarg instructions. Currently there
is conversion code to convert the old behavior to the new behavior.
However, converting from the current behavior to the old behavior is
very non-trivial.

Is bytecode compatibility for this feature important enough to try to do
the automatic coversion (if even possible?). And given that, can the
1.0 conversion code be dropped?

Andrew

So Alpha and some other potential targets (amd64?) use structs for
va_list. This is very much at odds with the current instructions and
intrinsics.

Yes, this is a serious issue.

And given that, can the 1.0 conversion code be dropped?

Yes, 1.0 is dead. Assuming people have 1.1 (and removing the code for dealing with 1.0) or later should be no problem for the LLVM 1.5 release. If you make this change, please add a note to the release notes.

So the question for the community is how much backwards compatibility
should be maintained for vaargs? Essentially the behavior needs to be
reverted to LLVM 1.0 semantics for vaarg instructions. Currently there
is conversion code to convert the old behavior to the new behavior.
However, converting from the current behavior to the old behavior is
very non-trivial.

Is bytecode compatibility for this feature important enough to try to do
the automatic coversion (if even possible?).

In the LLVM 1.x timeframe, I think that bytecode compatibility is very very important and .ll file compatibility is an absolute requirement. In my mind, I think the next release (LLVM 1.5) should come out in the next month or so. Ideally it would already be out, but I have personally been busy with other things so I haven't had much time to devote to it.

I'm not sure when LLVM 2.0 will happen. I think it would make sense to coincide it with some of the more drastic changes that I would like to eventually make to the LLVM type and exception system (described on my web page), but those changes certainly have no fixed schedule. If you can find a way to make the change while preserving at least .ll file compatibility, that would be the way to go.

I don't know how others feel about this idea, but one reasonable approach would be to add an explicit version number to the start of .ll files (.bc files already have one). In this case, the .ll file parser could realize that it has "new-new-style varargs" if the input file declares itself to be version 1.5 or later. Any files without a version number could be assumed to be in the old style.

Thoughts/comments/ideas?

-Chris

What about both behaviors? The current behavior is fine for most
current archs and we don't want to break compatibility. However, the
architectures this is currently a problem for have no backwards
compatibility to worry about. So, why not add the instructions for
those architectures, leaving the old archs using the old instructions.
Obviously, llvm-gcc would have to generate the correct instructions on a
per arch basis, and the CFE would need a little bit more code. When
LLVM 2.0 rolls around, all architectures can be moved to using the new
instructions, but until then, we simply have two sets of instructions to
do about the same thing. Granted this means .ll and .bc files are not
portable across architectures, but that seems like a much less serious
problem than what most other approaches would entail.

Andrew