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

Tue Apr 28 14:21:59 PDT 2020


> -----Original Message-----
> From: Fangrui Song <maskray at google.com>
> Sent: Tuesday, April 28, 2020 5:00 PM
> To: Robinson, Paul <paul.robinson at sony.com>
> Cc: David Blaikie <dblaikie at gmail.com>; llvm-dev <llvm-dev at lists.llvm.org>
> Subject: Re: [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.

If there are any proposals to make in this direction, they should have
their own llvm-dev thread so the discussion is not buried in some
otherwise largely uninteresting-to-many-people thread.
--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://urldefense.com/v3/__https://llvm.org/docs/DeveloperPolicy.html*ir-
> backwards-compatibility__;Iw!!JmoZiZGBv3RvKRSx!ukE3c19lDx9qmZLvc4-
> XEWhqWoBFUVmJEl5VZANMHvG3ovwp5FLRu-mpxdgf8tsQ5A$
> <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://urldefense.com/v3/__https://lists.llvm.org/cgi-
> bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!ukE3c19lDx9qmZLvc4-
> XEWhqWoBFUVmJEl5VZANMHvG3ovwp5FLRu-mpxdjpsS6FEw$
> <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://urldefense.com/v3/__https://lists.llvm.org/cgi-
> bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!ukE3c19lDx9qmZLvc4-
> XEWhqWoBFUVmJEl5VZANMHvG3ovwp5FLRu-mpxdjpsS6FEw$
> <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://urldefense.com/v3/__https://lists.llvm.org/cgi-
> bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!ukE3c19lDx9qmZLvc4-
> XEWhqWoBFUVmJEl5VZANMHvG3ovwp5FLRu-mpxdjpsS6FEw$