[llvm-dev] Question about versioning of LVVM IR

[Stanislav Pankevich via llvm-dev]

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>