Question about versioning of LVVM IR

Project Infrastructure LLVM Dev List Archives
1

Hello,

It is likely that I missing something however I have to ask.

We are working on Mull project https://github.com/mull-project which deals with
LLVM IR in the first place so it is often that we encounter errors like
the following one when we do things like parseAssemblyString(IR, Err, GlobalCtx);`:

test: <string>:7237:187: error: invalid field 'variable'
!1526 = distinct !DIGlobalVariable(name: "test_info_", linkageName: "_ZN14Hello_sup_Test10test_info_E", scope: !0, file: !1527, line: 4, type: !1528, isLocal: false, isDefinition: true, variable: %"class.testing::TestInfo"** @_ZN14Hello_sup_Test10test_info_E, declaration: !2817)

Quick research of recent LLVM commits reveals that stuff is being changed
significantly, example:

commit 7b500b4bdf40cb40cb33bdcf5faf900db4930824
Author: Adrian Prantl <aprantl@apple.com>

[IR] Remove the DIExpression field from DIGlobalVariable.

…

The questions are:

  1. why do Asm / LL parsers not produce warnings like:

“LLVM IR you are using has version 3.9 which is incompatible with current
supported version 4.0.”

  1. I didn’t find any special version markers in LLVM IR. My guess is that
    having them there would allow a developer who is changing LLVM IR format to
    put deprecation / backward incompatibility checks so that higher-level
    developers, like we are, see the friendly messages/warnings (see 1). It would

help us a lot to see that the reason is incompatibility, not any other reasons

like mistakes that we sometimes make.

Is there a reason why this kind of versioning is not being done in
AsmParser/LLParser?

Is it hard to have such functionality in place?

Background: we develop Mull as in-source project inside LLVM. We often
use stable LLVM distribution from brew and Rust stable/nightly compilers that are
often one version behind the latest stable version of LLVM. Currently our solution
is to stick to stable version of LLVM source tree however having a more friendly
output from AsmParser/LLParser would help us a lot to understand and debug
things faster and easier.

Thanks.

Stan

2

Hello,

It is likely that I missing something however I have to ask.

We are working on Mull project https://github.com/mull-project which deals with
LLVM IR in the first place so it is often that we encounter errors like
the following one when we do things like parseAssemblyString(IR, Err, GlobalCtx);`:

test: <string>:7237:187: error: invalid field 'variable'
!1526 = distinct !DIGlobalVariable(name: "test_info_", linkageName: "_ZN14Hello_sup_Test10test_info_E", scope: !0, file: !1527, line: 4, type: !1528, isLocal: false, isDefinition: true, variable: %"class.testing::TestInfo"** @_ZN14Hello_sup_Test10test_info_E, declaration: !2817)

Quick research of recent LLVM commits reveals that stuff is being changed
significantly, example:

commit 7b500b4bdf40cb40cb33bdcf5faf900db4930824
Author: Adrian Prantl <aprantl@apple.com>
Date: Tue Dec 20 02:09:43 2016 +0000

[IR] Remove the DIExpression field from DIGlobalVariable.

…

The questions are:

  1. why do Asm / LL parsers not produce warnings like:

"LLVM IR you are using has version 3.9 which is incompatible with current
supported version 4.0.”

Because the ASM is not portable from one version of LLVM to another.
The bitcode is intended to be supported across version.

http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility

  1. I didn’t find any special version markers in LLVM IR. My guess is that
    having them there would allow a developer who is changing LLVM IR format to
    put deprecation / backward incompatibility checks so that higher-level
    developers, like we are, see the friendly messages/warnings (see 1). It would

help us a lot to see that the reason is incompatibility, not any other reasons

like mistakes that we sometimes make.

Is there a reason why this kind of versioning is not being done in
AsmParser/LLParser?

Is it hard to have such functionality in place?

Background: we develop Mull as in-source project inside LLVM. We often
use stable LLVM distribution from brew and Rust stable/nightly compilers that are
often one version behind the latest stable version of LLVM. Currently our solution
is to stick to stable version of LLVM source tree however having a more friendly
output from AsmParser/LLParser would help us a lot to understand and debug
things faster and easier.

I’m not sure I understand exactly how you end up mix-and-matching versions of LLVM and assembly?

3

Hi Mehdi,

Thanks for the link. I knew about it but re-reading was useful in my case :slight_smile:

Now we are specifically careful about what versions we use to build the IR and then run it. Most common case before that was that we ran Orc JIT API from the latest source tree against .ll fixtures we built and stored before with earlier stable versions of LLVM.

My question was mainly about if it would make sense to LLVM developers to make the error message more explicit about the reasons of why IR is failing.

Stanislav

4

I suspect this is a maintenance tradeoff we would not want to make, but that’s just an opinion.