<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 2, 2017, at 1:21 AM, Stanislav Pankevich <<a href="mailto:s.pankevich@gmail.com" class="">s.pankevich@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><div class="">Hi Mehdi,<br class=""><br class=""></div>Thanks for the link. I knew about it but re-reading was useful in my case :)<br class=""><br class=""></div>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.<br class=""><br class=""></div>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.<br class=""></div></div></div></div></blockquote><div><br class=""></div><div>I suspect this is a maintenance tradeoff we would not want to make, but that’s just an opinion.</div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div>Stanislav<br class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jan 27, 2017 at 5:53 AM, Mehdi Amini <span dir="ltr" class=""><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><blockquote type="cite" class=""><span class=""><div class="">On Jan 26, 2017, at 1:56 AM, Stanislav Pankevich via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="m_-8089968479633589759Apple-interchange-newline"></span><div class=""><div dir="ltr" class=""><div class=""><div class=""><span class="">Hello,<br class=""><br class="">It is likely that I missing something however I have to ask.<br class=""><br class="">We are working on Mull project <a href="https://github.com/mull-project" target="_blank" class="">https://github.com/mull-<wbr class="">project</a> which deals with<br class="">LLVM IR in the first place so it is often that we encounter errors like<br class="">the following one when we do things like parseAssemblyString(IR, Err, GlobalCtx);`:<br class=""><br class="">```<br class="">test: <string>:7237:187: error: invalid field 'variable'<br class="">!1526 = distinct !DIGlobalVariable(name: "test_info_", linkageName: "_ZN14Hello_sup_Test10test_<wbr class="">info_E", scope: !0, file: !1527, line: 4, type: !1528, isLocal: false, isDefinition: true, variable: %"class.testing::TestInfo"** @_ZN14Hello_sup_Test10test_<wbr class="">info_E, declaration: !2817)<br class="">```<br class=""><br class="">Quick research of recent LLVM commits reveals that stuff is being changed<br class="">significantly, example:<br class=""><br class="">commit 7b500b4bdf40cb40cb33bdcf5faf90<wbr class="">0db4930824<br class="">Author: Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank" class="">aprantl@apple.com</a>><br class="">Date: Tue Dec 20 02:09:43 2016 +0000<br class=""><br class=""> [IR] Remove the DIExpression field from DIGlobalVariable.<br class=""><br class=""> ...<br class=""><br class="">The questions are:<br class=""><br class="">1) why do Asm / LL parsers not produce warnings like:<br class=""><br class="">"LLVM IR you are using has version 3.9 which is incompatible with current<br class=""></span>supported version 4.0.”</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Because the ASM is not portable from one version of LLVM to another. </div><div class="">The bitcode is intended to be supported across version.</div><div class=""><br class=""></div><div class=""><a href="http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility" target="_blank" class="">http://llvm.org/docs/<wbr class="">DeveloperPolicy.html#ir-<wbr class="">backwards-compatibility</a></div><span class=""><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><br class="">2) I didn't find any special version markers in LLVM IR. My guess is that<br class="">having them there would allow a developer who is changing LLVM IR format to<br class="">put deprecation / backward incompatibility checks so that higher-level<br class="">developers, like we are, see the friendly messages/warnings (see 1). It would<br class=""></div>help us a lot to see that the reason is incompatibility, not any other reasons<br class=""></div>like mistakes that we sometimes make.<br class=""><div class=""><div class=""><br class="">Is there a reason why this kind of versioning is not being done in<br class="">AsmParser/LLParser?<br class=""><br class="">Is it hard to have such functionality in place?<br class=""><br class="">Background: we develop `Mull` as in-source project inside LLVM. We often<br class="">use stable LLVM distribution from `brew` and Rust stable/nightly compilers that are <br class="">often one version behind the latest stable version of LLVM. Currently our solution<br class="">is to stick to stable version of LLVM source tree however having a more friendly<br class="">output from AsmParser/LLParser would help us a lot to understand and debug<br class="">things faster and easier.<br class=""></div></div></div></div></blockquote><div class=""><br class=""></div></span></div>I’m not sure I understand exactly how you end up mix-and-matching versions of LLVM and assembly?<div class=""><br class=""></div><div class="">— </div><span class="HOEnZb"><font color="#888888" class=""><div class="">Mehdi</div><div class=""><br class=""></div></font></span></div></blockquote></div><br class=""></div></div></div></div></div></div></div></div>
</div></blockquote></div><br class=""></body></html>