llvm dev - Jun 2014 - [LLVMdev] How to make sure the compatibility of LLVM IR

Hello all,

We have our own C++ language extension (based on Clang 3.2) and its special
backend (implemented in LLVM 3.2). Now we want to upgrade Clang to version
3.3 or 3.4, and the backend (llc) is still remained in LLVM 3.2.  (aka.
compile our own C++ language extension to LLVM 3.3/3.4 IR, and use LLVM 3.2
llc to generate its special backend assembly). I already know that LLVM
assembly has different syntax of attribute from LLVM 3.3 and LLVM 3.4 has a
new instruction - addrspacecast. I am wondering how to know the exhausted
incompatibility of LLVM IR?

Many thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140602/6aaf57da/attachment.html>

Hi,
> I am wondering how to know the exhausted incompatibility of LLVM IR?
Unfortunately, you're probably going to have a very hard time of it.
Compatibility in that direction isn't something LLVM either tries to
maintain or document. We try to make sure older bitcode files will
compile with newer versions of LLVM, though even that only works to an
extent.

The IR itself doesn't change *very* regularly (running "git log
docs/LanguageReference.rst" would give some idea of what's happened
since 3.2 -- I see ~150 since the 3.2 era). But how it's interpreted
and what backends are expected to cope with is more in flux. And the
API is almost certainly very different, so doing it all in a single
process would lead to a world of pain.

Cheers

Tim.

For what it's worth, Android maintains an LLVM 3.2 bitcode writer (
https://android.googlesource.com/platform/frameworks/compile/slang/+/master/BitWriter_3_2/).
I recently updated this to work with upstream LLVM @r209713. I know that
there are a few interested parties that would love to see this decoupled
and published as a separate library/utility, since there are now many
projects that chose ~3.2 as a relatively stable bitcode format.
Unfortunately, I never seem to have the time to be able to put it into a
separate form that would be suitable for other projects to use.

Steve


On Mon, Jun 2, 2014 at 7:37 AM, Tim Northover <t.p.northover at gmail.com>
wrote:
> Hi,
>
> > I am wondering how to know the exhausted incompatibility of LLVM IR?
>
> Unfortunately, you're probably going to have a very hard time of it.
> Compatibility in that direction isn't something LLVM either tries to
> maintain or document. We try to make sure older bitcode files will
> compile with newer versions of LLVM, though even that only works to an
> extent.
>
> The IR itself doesn't change *very* regularly (running "git log
> docs/LanguageReference.rst" would give some idea of what's
happened
> since 3.2 -- I see ~150 since the 3.2 era). But how it's interpreted
> and what backends are expected to cope with is more in flux. And the
> API is almost certainly very different, so doing it all in a single
> process would lead to a world of pain.
>
> Cheers
>
> Tim.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140605/5c12db86/attachment.html>