llvm dev - Apr 2020 - Backward compatibility of LLVM IR - ll/bc files

Quite often I get to work on an old bug, where an old ll/bc file is
attached as a testcase. These files, in most cases (if not all), need to be
converted somehow to the latest format, for the trunk version to be able to
parse it without an error.


So a few questions arise:

1. Is there a standard way to convert an old ll/bc to the latest? If not,
what is the common approach for these cases?

2. If there is no such tool, should we have one? (I think we should, of
course.)

3. What about automatically let the ll and bc Readers do the conversion
(internally)?

4. What about versions? Is there an RFC (probably old) for ll/bc file
versioning? (I know there is an optional record for version in the bc file
format, but it is not really utilized.)


Cheers,
Ehud.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200427/cb4a74d3/attachment.html>

I thought the binary bitcode reader was backwards compatible already.
That's what is documented here
https://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility

~Craig


On Sun, Apr 26, 2020 at 9:29 PM Ehud Katz via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Quite often I get to work on an old bug, where an old ll/bc file is
> attached as a testcase. These files, in most cases (if not all), need to be
> converted somehow to the latest format, for the trunk version to be able to
> parse it without an error.
>
>
> So a few questions arise:
>
> 1. Is there a standard way to convert an old ll/bc to the latest? If not,
> what is the common approach for these cases?
>
> 2. If there is no such tool, should we have one? (I think we should, of
> course.)
>
> 3. What about automatically let the ll and bc Readers do the conversion
> (internally)?
>
> 4. What about versions? Is there an RFC (probably old) for ll/bc file
> versioning? (I know there is an optional record for version in the bc file
> format, but it is not really utilized.)
>
>
> Cheers,
> Ehud.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20200426/cf236afc/attachment.html>

I admit I didn't know about that, but that is because I am handling a lot
of *old* bugs, older than LLVM version 3.0.
Version 3.0 has been released in Dec 1st 2011, and there are still many
bugs open from before that point.

The current BC Reader can't parse files produced by LLVM version 2.9 and
below (I've checked).
So, I wonder if there is anyone in favor, against (, or just doesn't care)
for supporting those versions?

On Mon, Apr 27, 2020 at 8:18 AM Craig Topper <craig.topper at gmail.com>
wrote:
> I thought the binary bitcode reader was backwards compatible already.
> That's what is documented here
> https://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility
>
> ~Craig
>
>
> On Sun, Apr 26, 2020 at 9:29 PM Ehud Katz via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Quite often I get to work on an old bug, where an old ll/bc file is
>> attached as a testcase. These files, in most cases (if not all), need
to be
>> converted somehow to the latest format, for the trunk version to be
able to
>> parse it without an error.
>>
>>
>> So a few questions arise:
>>
>> 1. Is there a standard way to convert an old ll/bc to the latest? If
not,
>> what is the common approach for these cases?
>>
>> 2. If there is no such tool, should we have one? (I think we should, of
>> course.)
>>
>> 3. What about automatically let the ll and bc Readers do the conversion
>> (internally)?
>>
>> 4. What about versions? Is there an RFC (probably old) for ll/bc file
>> versioning? (I know there is an optional record for version in the bc
file
>> format, but it is not really utilized.)
>>
>>
>> Cheers,
>> Ehud.
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://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/20200427/43c8dc38/attachment.html>