llvm dev - Jan 2017 - Question about versioning of LVVM IR

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 at 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."

2) 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170126/feb43691/attachment.html>

> On Jan 26, 2017, at 1:56 AM, Stanislav Pankevich via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
> 
> Hello,
> 
> It is likely that I missing something however I have to ask.
> 
> We are working on Mull project https://github.com/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 at apple.com <mailto:aprantl at
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

> 
> 2) 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?

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170126/bf145992/attachment.html>

Hi Mehdi,

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

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

On Fri, Jan 27, 2017 at 5:53 AM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
>
> On Jan 26, 2017, at 1:56 AM, Stanislav Pankevich via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> 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 at 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
>
>
>
> 2) 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?
>
> —
> Mehdi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170202/7d32464f/attachment.html>