On Tue, Jul 15, 2014 at 10:46 AM, John Criswell <jtcriswel at gmail.com> wrote:> On 7/15/14, 9:32 AM, Gaoyao Xiao wrote: > > 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.> > Regards, > > John Criswell > > > Thanks! > Gaoyao > > > _______________________________________________ > LLVM Developers mailing listLLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > 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/20140715/a28267ed/attachment.html>
On Tue, Jul 15, 2014 at 2:00 PM, Gaoyao Xiao <windxing2007 at gmail.com> wrote:> On Tue, Jul 15, 2014 at 10:46 AM, John Criswell <jtcriswel at gmail.com> > wrote: > >> On 7/15/14, 9:32 AM, Gaoyao Xiao wrote: >> >> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140715/5c1a31a3/attachment.html>
On Tue, Jul 15, 2014 at 5:12 PM, Reid Kleckner <rnk at google.com> wrote:> On Tue, Jul 15, 2014 at 2:00 PM, Gaoyao Xiao <windxing2007 at gmail.com> > wrote: > >> On Tue, Jul 15, 2014 at 10:46 AM, John Criswell <jtcriswel at gmail.com> >> wrote: >> >>> On 7/15/14, 9:32 AM, Gaoyao Xiao wrote: >>> >>> 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?> > >> 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. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140715/9e6e35df/attachment.html>
On 15 July 2014 22:00, Gaoyao Xiao <windxing2007 at gmail.com> wrote:>> 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 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