Does LLVM 3.5 works with IR from LLVM 3.0?

Hi,

I have some IR files which can be compiled using llc-3.0 and gcc-4.6.3. I want to instrument these IR files. My instrumentation pass is implemented under LLVM-3.5 and some data structures in LLVM-3.5 are not available on LLVM-3.0, such as AttributeSet in Attribute.h. I tried to compile my instrumentation pass under LLVM-3.0 and it failed due to missing data types. So I am asking whether it is possible to use LLVM-3.5 to instrument the IR files? If not, is there any walk around?

Thanks!
Gaoyao

I believe LLVM 3.5 is supposed to be able to read bitcode files from LLVM 3.0. It is possible, though, that bugs may prevent this from working. If it doesn’t work, you should probably file a bug report with (if possible) a reduced test case. If reading the old bitcode files directly into opt/clang/whatever doesn’t work, try disassembling the bitcode into an assembly file with llvm-dis from LLVM 3.0 and re-assembling the output using llvm-as from LLVM 3.5: llvm-dis-3.0 -f -o - file.bc | llvm-as-3.5 -f -o newfile.bc Regards, John Criswell

Not having tests for that makes it really hard to be sure it works,
and we didn't particularly kept it as a design goal throughout
development since then.

Things like how unions and structures are represented and marshaled,
how functions are called (PCS) and more drastically debug metadata
have changed so much that it'd be near impossible to read any
reasonably sized 3.0 IR with the current tools.

cheers,
--renato

> I believe LLVM 3.5 is supposed to be able to read bitcode files from LLVM
> 3.0.

Not having tests for that makes it really hard to be sure it works,
and we didn't particularly kept it as a design goal throughout
development since then.

Yeah, we have a thread floating around ("Clarification on the backward
compatibility promises") where we're trying to even decide on what our
official compatibility promise is.

-- Sean Silva

Hi,

I have some IR files which can be compiled using llc-3.0 and gcc-4.6.3.
I want to instrument these IR files. My instrumentation pass is implemented
under LLVM-3.5 and some data structures in LLVM-3.5 are not available on
LLVM-3.0, such as *AttributeSet* in *Attribute.h*. I tried to compile my
instrumentation pass under LLVM-3.0 and it failed due to missing data
types. So I am asking whether it is possible to use LLVM-3.5 to instrument
the IR files? If not, is there any walk around?

I believe LLVM 3.5 is supposed to be able to read bitcode files from LLVM
3.0. It is possible, though, that bugs may prevent this from working. If
it doesn't work, you should probably file a bug report with (if possible) a
reduced test case.

If reading the old bitcode files directly into opt/clang/whatever doesn't
work, try disassembling the bitcode into an assembly file with llvm-dis
from LLVM 3.0 and re-assembling the output using llvm-as from LLVM 3.5:

opt and clang can read the bitcode but the produced binary cannot run.

llvm-dis-3.0 -f -o - file.bc | llvm-as-3.5 -f -o newfile.bc

I tried this and the newfile.bc is incorrect. newfile.bc can be compiled to
binary but cannot run.

I also tried to this:

*llvm-dis-3.0 -f -o - file.bc | llvm-as-3.5 -f -o newfile.bcllvm-dis-3.5 -f
-o newfile.bc | llvm-as-3.0 -o newnewfile.bc*
llvm-as-3.0 fails and give errors as below:
llvm-as:
/home/jun/New_SecondWrite_Output/benchmarks/bzip2_O3/bzip2_O3-3.5.ll:43:37:
error: expected top-level entity
declare void @perror(i8* nocapture) #0

So it seems llvm3.5 indeed is incompatible with llvm3.0.

> I believe LLVM 3.5 is supposed to be able to read bitcode files from LLVM
> 3.0.

Not having tests for that makes it really hard to be sure it works,
and we didn't particularly kept it as a design goal throughout
development since then.

Things like how unions and structures are represented and marshaled,
how functions are called (PCS) and more drastically debug metadata
have changed so much that it'd be near impossible to read any
reasonably sized 3.0 IR with the current tools.

It seems my test verifies you're correct that they are incompatible.
Thanks.

Hi,

I have some IR files which can be compiled using llc-3.0 and
gcc-4.6.3. I want to instrument these IR files. My instrumentation pass is
implemented under LLVM-3.5 and some data structures in LLVM-3.5 are not
available on LLVM-3.0, such as *AttributeSet* in *Attribute.h*. I tried
to compile my instrumentation pass under LLVM-3.0 and it failed due to
missing data types. So I am asking whether it is possible to use LLVM-3.5
to instrument the IR files? If not, is there any walk around?

I believe LLVM 3.5 is supposed to be able to read bitcode files from LLVM
3.0. It is possible, though, that bugs may prevent this from working. If
it doesn't work, you should probably file a bug report with (if possible) a
reduced test case.

If reading the old bitcode files directly into opt/clang/whatever doesn't
work, try disassembling the bitcode into an assembly file with llvm-dis
from LLVM 3.0 and re-assembling the output using llvm-as from LLVM 3.5:

opt and clang can read the bitcode but the produced binary cannot run.

llvm-dis-3.0 -f -o - file.bc | llvm-as-3.5 -f -o newfile.bc

I tried this and the newfile.bc is incorrect. newfile.bc can be compiled
to binary but cannot run.

This would be good to debug. There isn't enough info here to know what
went wrong.

I also tried to this:

*llvm-dis-3.0 -f -o - file.bc | llvm-as-3.5 -f -o newfile.bcllvm-dis-3.5
-f -o newfile.bc | llvm-as-3.0 -o newnewfile.bc*

This obviously won't work. We will generate newer LLVM assembly than the
old llvm-as can read.

Hi,

I have some IR files which can be compiled using llc-3.0 and
gcc-4.6.3. I want to instrument these IR files. My instrumentation pass is
implemented under LLVM-3.5 and some data structures in LLVM-3.5 are not
available on LLVM-3.0, such as *AttributeSet* in *Attribute.h*. I tried
to compile my instrumentation pass under LLVM-3.0 and it failed due to
missing data types. So I am asking whether it is possible to use LLVM-3.5
to instrument the IR files? If not, is there any walk around?

I believe LLVM 3.5 is supposed to be able to read bitcode files from
LLVM 3.0. It is possible, though, that bugs may prevent this from
working. If it doesn't work, you should probably file a bug report with
(if possible) a reduced test case.

If reading the old bitcode files directly into opt/clang/whatever
doesn't work, try disassembling the bitcode into an assembly file with
llvm-dis from LLVM 3.0 and re-assembling the output using llvm-as from LLVM
3.5:

opt and clang can read the bitcode but the produced binary cannot run.

llvm-dis-3.0 -f -o - file.bc | llvm-as-3.5 -f -o newfile.bc

I tried this and the newfile.bc is incorrect. newfile.bc can be compiled
to binary but cannot run.

This would be good to debug. There isn't enough info here to know what
went wrong.

The only error from the compiled bzip2 binary is:
*Could not translate address: 0xa0048000*

I tried several other spec2006 programs and the error is similar with
different addresses. Since my instrumentation is quite simple, I am
thinking rewrite it for llvm-3.0 and that might be quicker. Do you have any
hint based on the short error message?

This may not be perfect, but it is expected. The only guarantees of
compatibility between front-end and back-ends (linked by IR) is that
release X tools will work with release X back-ends, and that trunk
tools will work with trunk back-ends. Everything else is unknown,
unspecified and untested.

There hasn't been, to my knowledge, any effort into standardizing LLVM
IR into a language per se, which could be implemented like C or Dwarf,
by having standard levels based on release year or major/minor
revisions. We do have the LangRef document for every major release,
but the IR libraries did not require backwards compatibility, so
support was never done to match.

Supporting legacy IR is not as simple as it sounds, because ABI
decisions are taken every day to better implement the standards and
the targets in which we run, and interpreting different patterns as
similar concepts (or vice versa) would be a huge addendum to the
current code that deals with it. In summary, I don't think we'd ever
have that as a language.

As has been said many times before, but it's always good to repeat:
LLVM IR is a compiler IR. [1]

cheers,
--renato

[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html