All,
Our plan in 2.0 for backwards compatibility with llvm-1.9 is to provide
a translator for upgrading from 1.9 to 2.0 llvm assembly. The tool will
be named llvm-upgrade and used something like this:
llvm-1.9/bin/llvm-dis < 1.9.bc | llvm-2.0/bin/llvm-upgrade |
llvm-2.0/bin/llvm-as -o 2.0.bc
The 2.0 assembly and bytecode are going to be significantly different
and this approach offers us a clean slate for implementing the bcreader
and asmparser. Additionally, much of the upgrade code would
significantly slow down and congest the current implementation. By
placing all that logic in a single tool, we provide an upgrade path
while also providing the most efficient bcreader and asmparser possible
in 2.0.
The question is, when can you tolerate the cut over?
It will definitely happen on the CVS head before 2.0 is released. I
would like it to happen in the next week so that we can unclutter the
bcreader and asmparser for (pre-release) 2.0 users.
If you work exclusively on the CVS/SVN head, this shouldn't affect you.
It would only affect people retaining 1.9 bytecode/assembly files and
using them with llvm (pre-release) 2.0.
Any objections to doing this next week (assuming llvm-upgrade is done
and working)?
Reid.
