Why does new llvm-as reject old IR format?

Hi all,
I have the below input

define i32 @myCas(i32* %ptr, i32 %cmp, i32 %val) #0 {

entry:
%0 = cmpxchg volatile i32* %ptr, i32 %cmp, i32 %val seq_cst
%1 = extractvalue { i32, i1 } %0, 0
ret i32 %1
}

When I provide this input file to llvm-as 3.6 I get the error

a.ll: error: Expected ordering on atomic instruction
%1 = extractvalue { i32, i1 } %0, 0

This is because instruction syntax of cmpxchg has changed since 3.2 requiring failing order as well.

Ideally, I would expect backward compatibility from LLVM tools; and not requiring to modify the code again.

What is LLVM’s philosophy here?

We support backwards compatibility (i.e. newer tools can read older
files) on .bc files but not .ll files. This goes back to version 3.0
so nothing new can read files from the 2.9 or earlier era and the
other direction (older tools reading newer files) is never going to
work.

We're in the middle of changing our version numbering and official
policy, but the general sense is that we have no intent to break this.

So for your particular problem you should be able to use a 3.2 llvm-as
and then do what you like with the .bc file.

Cheers.

Tim.

Surprised to know that backward compatibility is not honored across the tools.
(i.e. you can read old .bc but NOT old .ll files)
Supporting latter is more useful, IMO, because then I wouldn’t have to modify all my sources.

And who are “we” here?

Surprised to know that backward compatibility is not honored across the
tools.
(i.e. you can read old .bc but NOT old .ll files)
Supporting latter is more useful, IMO, because then I wouldn't have to
modify all my sources.

It's been that way for LLVM's entire existence. One could imagine ways to
allow for source-level IR compatibility as well, but, at the moment there
isn't any such promise.

See:
http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility

And who are "we" here?

"We" is the LLVM community, since that is the official policy of the LLVM
project.

Ok, Thanks a lot!