[LLVMdev] IMPORTANT: Working On HEAD before Release 1.9

[Reid Spencer]

All,

As you may know, I'm working on making several instructions have signed
and/or floating point variants. For example, yesterday I committed
changes to replace the DIV instruction with SDIV, UDIV, and FDIV.  These
instruction changes are increments towards getting rid of signed types
completely in LLVM.  To reduce confusion, here's some things you need to
know if you're planning to use the CVS HEAD version before the 1.9
release:

1. Release 1.9 will correspond to bytecode version 6.
2. Release 1.8 corresponds to bytecode version 5.
3. All versions of llvm-gcc/llvm prior to 11:00pm 2006-10-25 PDT will
generate 
   version 5 bytecode files. After that it llvm generates version 6.
4. Version 5 (and earlier) bytecode files will always auto-upgrade to
version 6.
5. The assembly parser will always auto-upgrade the old instruction
mnemonics. For 
   example, DIV will be automatically converted to SDIV, UDIV or FDIV
based on the
   operand types. Similarly for the other instructions to be changed.
6. The distinction between unsigned and signed types probably won't go
away before 
   release time. That is, we'll still have UByteTy and SByteTy, etc. The
change to 
   merge those to "Int8" will occur after the 1.9 release accompanied by
another 
   bytecode version change (version 7). Similarly for Short, Int and
Long.
7. Until Release 1.9 goes out the door (Nov 6th), the definition of
version 6 bytecode 
   is in flux. Last night's commit of the DIV instruction changes
introduced version 6
   of the bytecode, or at least the first incarnation of it.  Each
subsequent patch
   for signed instructions (REM, CAST SHR, SETCC) will alter the
definition of 
   version 6 bytecode because of new instruction opcodes being
introduced. So, if you
   start using the CVS HEAD version of llvm and generate version 6
bytecode files now,
   they may not be readable in the near future as the subsequent signed
instruction
   patches are introduced. That is, each patch will change the
definition of version
   6 bytecode. This situation will only last for at most 2 weeks, not
past the
   release date for 1.9. 

Here's the moral of the story:

If you don't want to be impacted by the changing definition of version 6
bytecode, please retain your version 5 bytecode files and possibly a
version of llvm-gcc that generates version 5 bytecode files. Since
version 5 bytecode files will auto-upgrade regardless of the definition
of version 6, you should be fine.  This issue goes away after the 1.9
release is made when the version 6 bytecode definition will be cast in
stone.

If you have questions or concerns, please feel free to follow up with me
here or on the IRC channel.

Best Regards,

Reid.