llvm dev - Aug 2016 - Why does new llvm-as reject old IR format?

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>

On Fri, Aug 12, 2016 at 10:05 AM, Madhur Amilkanthwar via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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.

>  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
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160812/48237b65/attachment.html>

Ok, Thanks a lot!

On Fri, Aug 12, 2016 at 7:42 PM, James Y Knight <jyknight at google.com>
wrote:
> On Fri, Aug 12, 2016 at 10:05 AM, Madhur Amilkanthwar via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 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.
>
>
>>  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
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>

-- 
*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/e0405182/attachment.html>