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
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
version 5 bytecode files. After that it llvm generates version 6.
4. Version 5 (and earlier) bytecode files will always auto-upgrade to
5. The assembly parser will always auto-upgrade the old instruction
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
release time. That is, we'll still have UByteTy and SByteTy, etc. The
merge those to "Int8" will occur after the 1.9 release accompanied by
bytecode version change (version 7). Similarly for Short, Int and
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
for signed instructions (REM, CAST SHR, SETCC) will alter the
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
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
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
If you have questions or concerns, please feel free to follow up with me
here or on the IRC channel.