llvm dev - Aug 2016 - 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?



-- 
*Disclaimer: Views, concerns, thoughts, questions, ideas expressed in this
mail are of my own and my employer has no take in it. *
Thank You.
Madhur D. Amilkanthwar
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160812/7ca4f96a/attachment.html>

On 12 August 2016 at 06:42, Madhur Amilkanthwar via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 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?

On Fri, Aug 12, 2016 at 7:21 PM, Tim Northover <t.p.northover at
gmail.com>
wrote:
> On 12 August 2016 at 06:42, Madhur Amilkanthwar via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > 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.
>


-- 
*Disclaimer: Views, concerns, thoughts, questions, ideas expressed in this
mail are of my own and my employer has no take in it. *
Thank You.
Madhur D. Amilkanthwar
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160812/89b026f8/attachment.html>