[PATCH] Bitcode: Add bitcode format compatibility test

Duncan P. N. Exon Smith dexonsmith at apple.com
Fri Jul 31 10:30:00 PDT 2015


> On 2015-Jul-31, at 10:22, Vedant Kumar <vsk at apple.com> wrote:
> 
>> LangRef might work, but it would probably be lost among all the stuff there; the argument could also be made that LangRef is basically about the IR itself, but this content is more about development process/tasks.
> 
> I buy that argument.
> 
>> http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility is another possibility, which I'm leaning towards, since this is all in connection with compatibility.
>> 
>> Another possibility is to add it as an explicit task in http://llvm.org/docs/HowToReleaseLLVM.html, but that may implicitly put the burden of doing this on the release manager, which may not be intended (maybe could be added as "track down somebody to do this once we've branched"?).
> 
> HowToReleaseLLVM seems a bit high-level for this sort of task. I think the DeveloperPolicy document is a good place.
> 
> Here's the wording I picked:
> 
>> * The bitcode format produced by a X.Y release will be readable by all
>>  following X.Z releases and the (X+1).0 release. To help ensure this, an X.Y
>>  version of ``test/Bitcode/compatibility.ll`` should be assembled and
>>  committed before each release.
> 
> 
> I updated the file paths and comments per Duncan's suggestion. Updated patch attached.
> 
> <bccompat-submit.patch>

LGTM with a couple minor changes; I'll commit for you after.

> diff --git a/docs/DeveloperPolicy.rst b/docs/DeveloperPolicy.rst
> index 4ee43fc..25f302f 100644
> --- a/docs/DeveloperPolicy.rst
> +++ b/docs/DeveloperPolicy.rst
> @@ -505,8 +505,10 @@ for llvm users and not imposing a big burden on llvm developers:
>  * The textual format is not backwards compatible. We don't change it too often,
>    but there are no specific promises.
>  
> -* The bitcode format produced by a X.Y release will be readable by all following
> -  X.Z releases and the (X+1).0 release.
> +* The bitcode format produced by a X.Y release will be readable by all
> +  following X.Z releases and the (X+1).0 release. To help ensure this, an X.Y
> +  version of ``test/Bitcode/compatibility.ll`` should be assembled and
> +  committed before each release.

s/before/after/

>  
>  * Newer releases can ignore features from older releases, but they cannot
>    miscompile them. For example, if nsw is ever replaced with something else,

Please also add a point (maye earlier?) stating that new/changed IR constructs
should get added to test/Bitcode/compatibility.ll.

> diff --git a/test/Bitcode/compatibility.ll b/test/Bitcode/compatibility.ll
> new file mode 100644
> index 0000000..46aebba
> --- /dev/null
> +++ b/test/Bitcode/compatibility.ll
> @@ -0,0 +1,1275 @@
> +; Bitcode compatibility test for llvm-3.7

This shouldn't mention llvm-3.7; this is for trunk.

However, it should duplicate the info from docs/DeveloperPolicy.rst (and
reference it).

> +
> +; RUN: llvm-as < %s | llvm-dis | llvm-as | llvm-dis | FileCheck %s
> +; RUN: verify-uselistorder < %s





More information about the llvm-commits mailing list