thr3ads.net - llvm dev - [llvm-dev] Backward compatibility of LLVM IR

If this information is useful, please help other people find it:
Share via:

David Blaikie via llvm-dev

2020-Apr-28 01:22 UTC

[llvm-dev] Backward compatibility of LLVM IR - ll/bc files

On Mon, Apr 27, 2020 at 6:42 AM Robinson, Paul via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Older releases are still available for download at releases.llvm.org; I
> believe the 3.0 release was supposed to be able to read 2.x bitcode, so you
> should be able to upgrade the bitcode with 3.0 tools and proceed from
> there.  I **think** everything since 3.0 is still readable by current
> tools.
>
>
>
> The project generally has not favored indefinite backward compatibility.
> There have not been any major bitcode format changes since then, so there
> has been little motivation to declare another compatibility break.  Being
> able to read 9-year-old bitcode does not seem like a valuable feature,
> given the above workaround.
>
>
>
> Let me say, though, that I fully support efforts to review and address old
> bugs.  The LLVM project as a whole fixes (or otherwise closes) only about
> 2/3 of reported bugs.  Improving that statistic would be very nice.
>
Agreed - though not sure what the chance of bugs that old still being
relevant, given how much LLVM changes over time. If most of those older
bugs are no longer relevant, it might be more useful to mass-close them and
spend the effort that might've gone into reproducing/updating them into
looking at more recent bugs. But certainly "dealer's choice" - if
looking
at older bugs takes someone's fancy especially, that's cool :)

- Dave

> --paulr
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of
*Ehud
> Katz via llvm-dev
> *Sent:* Monday, April 27, 2020 3:52 AM
> *To:* Craig Topper <craig.topper at gmail.com>
> *Cc:* llvm-dev <llvm-dev at lists.llvm.org>
> *Subject:* Re: [llvm-dev] Backward compatibility of LLVM IR - ll/bc files
>
>
>
> 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
>
> _______________________________________________
> 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/7d2062b7/attachment.html>

Robinson, Paul via llvm-dev

2020-Apr-28 14:27 UTC

head link

[llvm-dev] Backward compatibility of LLVM IR - ll/bc files

On a lark, I skimmed the headlines of the 500 oldest open bugs.  Sure a bunch of
them are likely to be irrelevant now (I see some reported against dragonegg for
example), but not all of them—some are still reasonable feature requests for
example.  I’d argue against a mass closure purely on the basis of age.
--paulr

From: David Blaikie <dblaikie at gmail.com>
Sent: Monday, April 27, 2020 9:22 PM
To: Robinson, Paul <paul.robinson at sony.com>
Cc: Ehud Katz <ehudkatz at gmail.com>; Craig Topper <craig.topper at
gmail.com>; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Backward compatibility of LLVM IR - ll/bc files

On Mon, Apr 27, 2020 at 6:42 AM Robinson, Paul via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Older releases are still available for download at
releases.llvm.org<https://urldefense.com/v3/__http:/releases.llvm.org__;!!JmoZiZGBv3RvKRSx!rUhXj-1epP4UoESOjm7poOvJbstYMh5PexXInF1nmj1h7s49pc9cvDncHpOILESU2g$>;
I believe the 3.0 release was supposed to be able to read 2.x bitcode, so you
should be able to upgrade the bitcode with 3.0 tools and proceed from there.  I
*think* everything since 3.0 is still readable by current tools.

The project generally has not favored indefinite backward compatibility.  There
have not been any major bitcode format changes since then, so there has been
little motivation to declare another compatibility break.  Being able to read
9-year-old bitcode does not seem like a valuable feature, given the above
workaround.

Let me say, though, that I fully support efforts to review and address old bugs.
The LLVM project as a whole fixes (or otherwise closes) only about 2/3 of
reported bugs.  Improving that statistic would be very nice.

Agreed - though not sure what the chance of bugs that old still being relevant,
given how much LLVM changes over time. If most of those older bugs are no longer
relevant, it might be more useful to mass-close them and spend the effort that
might've gone into reproducing/updating them into looking at more recent
bugs. But certainly "dealer's choice" - if looking at older bugs
takes someone's fancy especially, that's cool :)

- Dave

--paulr

From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces
at lists.llvm.org>> On Behalf Of Ehud Katz via llvm-dev
Sent: Monday, April 27, 2020 3:52 AM
To: Craig Topper <craig.topper at gmail.com<mailto:craig.topper at
gmail.com>>
Cc: llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at
lists.llvm.org>>
Subject: Re: [llvm-dev] Backward compatibility of LLVM IR - ll/bc files

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<mailto: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<https://urldefense.com/v3/__https:/llvm.org/docs/DeveloperPolicy.html*ir-backwards-compatibility__;Iw!!JmoZiZGBv3RvKRSx!rUhXj-1epP4UoESOjm7poOvJbstYMh5PexXInF1nmj1h7s49pc9cvDncHpOXeuBhUw$>

~Craig

On Sun, Apr 26, 2020 at 9:29 PM Ehud Katz via llvm-dev <llvm-dev at
lists.llvm.org<mailto: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<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!rUhXj-1epP4UoESOjm7poOvJbstYMh5PexXInF1nmj1h7s49pc9cvDncHpMebNSrGQ$>
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!rUhXj-1epP4UoESOjm7poOvJbstYMh5PexXInF1nmj1h7s49pc9cvDncHpMebNSrGQ$>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200428/1e766abe/attachment.html>

Fangrui Song via llvm-dev

2020-Apr-28 21:00 UTC

head link

[llvm-dev] Backward compatibility of LLVM IR - ll/bc files

On 2020-04-28, Robinson, Paul via llvm-dev wrote:>On a lark, I skimmed the headlines of the 500 oldest open bugs.  Sure a
bunch of them are likely to be irrelevant now (I see some reported against
dragonegg for example), but not all of them—some are still reasonable feature
requests for example.  I’d argue against a mass closure purely on the basis of
age.
>--paulr
This may be where a bot auto closing inactive issues might be useful.
The bot can ping the reporter and commenter and close the bug if there
is no response for a specified number of days.
>From: David Blaikie <dblaikie at gmail.com>
>Sent: Monday, April 27, 2020 9:22 PM
>To: Robinson, Paul <paul.robinson at sony.com>
>Cc: Ehud Katz <ehudkatz at gmail.com>; Craig Topper <craig.topper
at gmail.com>; llvm-dev at lists.llvm.org
>Subject: Re: [llvm-dev] Backward compatibility of LLVM IR - ll/bc files
>
>On Mon, Apr 27, 2020 at 6:42 AM Robinson, Paul via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
>Older releases are still available for download at
releases.llvm.org<https://urldefense.com/v3/__http:/releases.llvm.org__;!!JmoZiZGBv3RvKRSx!rUhXj-1epP4UoESOjm7poOvJbstYMh5PexXInF1nmj1h7s49pc9cvDncHpOILESU2g$>;
I believe the 3.0 release was supposed to be able to read 2.x bitcode, so you
should be able to upgrade the bitcode with 3.0 tools and proceed from there.  I
*think* everything since 3.0 is still readable by current tools.
>
>The project generally has not favored indefinite backward compatibility. 
There have not been any major bitcode format changes since then, so there has
been little motivation to declare another compatibility break.  Being able to
read 9-year-old bitcode does not seem like a valuable feature, given the above
workaround.
>
>Let me say, though, that I fully support efforts to review and address old
bugs.  The LLVM project as a whole fixes (or otherwise closes) only about 2/3 of
reported bugs.  Improving that statistic would be very nice.
>
>Agreed - though not sure what the chance of bugs that old still being
relevant, given how much LLVM changes over time. If most of those older bugs are
no longer relevant, it might be more useful to mass-close them and spend the
effort that might've gone into reproducing/updating them into looking at
more recent bugs. But certainly "dealer's choice" - if looking at
older bugs takes someone's fancy especially, that's cool :)
>
>- Dave
>
>--paulr
>
>From: llvm-dev <llvm-dev-bounces at
lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org>> On Behalf Of
Ehud Katz via llvm-dev
>Sent: Monday, April 27, 2020 3:52 AM
>To: Craig Topper <craig.topper at gmail.com<mailto:craig.topper at
gmail.com>>
>Cc: llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at
lists.llvm.org>>
>Subject: Re: [llvm-dev] Backward compatibility of LLVM IR - ll/bc files
>
>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<mailto: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<https://urldefense.com/v3/__https:/llvm.org/docs/DeveloperPolicy.html*ir-backwards-compatibility__;Iw!!JmoZiZGBv3RvKRSx!rUhXj-1epP4UoESOjm7poOvJbstYMh5PexXInF1nmj1h7s49pc9cvDncHpOXeuBhUw$>
>
>~Craig
>
>
>On Sun, Apr 26, 2020 at 9:29 PM Ehud Katz via llvm-dev <llvm-dev at
lists.llvm.org<mailto: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<mailto:llvm-dev at lists.llvm.org>
>https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!rUhXj-1epP4UoESOjm7poOvJbstYMh5PexXInF1nmj1h7s49pc9cvDncHpMebNSrGQ$>
>_______________________________________________
>LLVM Developers mailing list
>llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
>https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!rUhXj-1epP4UoESOjm7poOvJbstYMh5PexXInF1nmj1h7s49pc9cvDncHpMebNSrGQ$>
>_______________________________________________
>LLVM Developers mailing list
>llvm-dev at lists.llvm.org
>https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

[llvm-dev] Backward compatibility of LLVM IR - ll/bc files

[llvm-dev] Backward compatibility of LLVM IR - ll/bc files

[llvm-dev] Backward compatibility of LLVM IR - ll/bc files