llvm dev - Mar 2005 - [LLVMdev] 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

On Tue, 29 Mar 2005, Andrew Lenharth wrote:
> 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

-- 
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/

On Sat, 2005-04-02 at 23:48 -0600, Chris Lattner wrote:
> On Tue, 29 Mar 2005, Andrew Lenharth wrote:
> > 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.
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