Displaying 2 results from an estimated 2 matches for "r163185".
2014 Jun 17
8
[LLVMdev] Clarification on the backward compatibility promises
...Something like x.y should be able to
> read stuff from x.y-1, but x.y+2 is allowed not to read stuff there,
> so the proper path is transition x.y-1 => x.y => x.y+2. Am I right?
That doesn't match what we have in trunk right now. For example, we
changed how inline asm is stored in r163185 (Sep 5 2012), but we still
support reading the old one. This is one of the cases where we have a
FIXME about 4.0.
> 2. Metadata compatibility. We already had precedence of introducing
> incompatible changes into metadata format in the past within release.
> Should we use relaxes rules for...
2014 Jun 17
3
[LLVMdev] Clarification on the backward compatibility promises
A bit of history first:
Back when we transitioned from bytecode to bitcode (2.0) we had a tool
called llvm-upgrade which would read .ll files from 1.9 and output 2.0
format which could then be passed to llvm-as to produce bitcode.
The release notes for 2.3 note that llvm-upgrade was not supported any more.
During the 2.X development we tried to keep reading older bitcodes.
Once we got to 3.1,