Reid Spencer
2006-Oct-26 21:02 UTC
[LLVMdev] IMPORTANT: Working On HEAD before Release 1.9
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.