Hmm.. I didn't explain the problem completely last time. I am creating a drop-in replacement for gcc and gfortran that runs an additional pass on the bitcode before generating the native binary. Here's whats happening: If the source code compilation process builds a static library (.a archive file), I need a means to link the `.a' file statically into the application. So if the original statement was: gfortran file.o -L somedir -lmylib -o file then my modified compilation process would have to deal with file.o and libmylib.a to generate the binary `file'. Now, all files essentially contain bitcode (file.o and object files inside libmylib.a). So the pseudo-code would look like: -- QUOTE -- For all input files passed to compiler: If extension is .o: Use llc to generate .s file Add this filename to some collection Else if extension is .a: Extract contents of this archive Use llc on each file to generate .s file Add each filename to the collection End if End for Retrieve all `.s' filenames and pass them all to gcc or gfortran -- UNQUOTE -- But the part that deals with `.a' files is a bit ugly. llvm-ld handles the archive (.a) files without any manual extraction but I fear that because llvm-ld is not a full-featured linker, I might run into a wall because of incompatible options between gfortran/gcc and llvm-ld. Ashay On Mon, Sep 12, 2011 at 3:38 PM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote:> Sorry, at what step do you need archive? llc emits binary, it does not > perform any linking, thus it does not need anything except the input > bytecode file. Then during linking you can link whatever archives of > binaries you want. > > 2011/9/13 Ashay Rane <ashay.rane at tacc.utexas.edu>: > > Thats correct. But using llc becomes a problem when I have archives (.a > > files). I could, in theory, extract its contents to a tempdir and then > use > > llc and link but just wondering if there is a more elegant solution. > > Ashay > > > > On Mon, Sep 12, 2011 at 3:00 PM, Dmitry N. Mikushin <maemarcus at gmail.com > > > > wrote: > >> > >> Ashay, > >> > >> If I understand correctly, in hw.o you would have llvm bytecode, while > >> linker expects regular object binary. Probably first you need to emit > >> asm out of bytecode using llc? > >> > >> - D. > >> > >> 2011/9/12 Ashay Rane <ashay.rane at tacc.utexas.edu>: > >> > Hello, > >> > Sorry for the late reply. Using dragonegg worked well, thanks all! > >> > Just as a note... I had to use llvm-ld during the link step because > >> > gfortran > >> > could not link bitcode. Here's an example of the error shown when > using > >> > gfortran instead of llvm-ld: > >> > $ ${GCC_4_5_0}/bin/gfortran hw.f -c > >> > -fplugin=${DRAGONEGG_PLUGIN}/dragonegg.so -o hw.o -flto -emit-llvm -S > >> > $ ${LLVM_2_9}/bin/opt -mem2reg hw.o -o hw.o > >> > $ ${GCC_4_5_0}/bin/gfortran > >> > > >> > > -fplugin=${DRAGONEGG_PLUGIN}/dragonegg.so ${GCC_4_5_0}/lib64/libgfortran.a > >> > hw.o -o hw > >> > hw.o: file not recognized: File format not recognized > >> > collect2: ld returned 1 exit status > >> > $ file hw.o > >> > hw.o: data > >> > Instead, using llvm-ld: > >> > $ ${LLVM_2_9}/bin/llvm-ld -native hw.o -o hw > >> > ${GCC_4_5_0}/lib64/libgfortran.a -lm > >> > llvm-gcc had the gold plugin. I wonder if there is any equivalent of > >> > that > >> > for dragonegg to be able to compile bitcode and native object code in > a > >> > transparent manner. > >> > Thanks again! > >> > Ashay > >> > > >> > On Wed, Aug 31, 2011 at 4:29 PM, Anton Korobeynikov > >> > <anton at korobeynikov.info> wrote: > >> >> > >> >> Hello > >> >> > >> >> > I am not very familiar with Fortran programs. I saw a few programs > >> >> > that > >> >> > had > >> >> > a "MAIN" subroutine defined, some others that did not. Am I missing > >> >> > something while compiling the code? Is there a different way to > >> >> > compile > >> >> > bitcode (from Fortran programs) to a native binary? > >> >> For Fortran MAIN is indeed something similar to C main, but not > >> >> exactly the same. > >> >> You have to link the runtime library (libgfortran.a) in order to get > >> >> "proper" main, mak sure all stuff is initialized properly, etc. > >> >> > >> >> -- > >> >> With best regards, Anton Korobeynikov > >> >> Faculty of Mathematics and Mechanics, Saint Petersburg State > University > >> > > >> > > >> > _______________________________________________ > >> > 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/20110912/a1e2575a/attachment.html>
I see. And what's the purpose for outputting bitcode into *.o and *.a files? Do you want to perform an LLVM pass on linking step? 2011/9/13 Ashay Rane <ashay.rane at tacc.utexas.edu>:> Hmm.. I didn't explain the problem completely last time. I am creating a > drop-in replacement for gcc and gfortran that runs an additional pass on the > bitcode before generating the native binary. Here's whats happening: If the > source code compilation process builds a static library (.a archive file), I > need a means to link the `.a' file statically into the application. So if > the original statement was: > gfortran file.o -L somedir -lmylib -o file > then my modified compilation process would have to deal with file.o and > libmylib.a to generate the binary `file'. Now, all files essentially contain > bitcode (file.o and object files inside libmylib.a). So the pseudo-code > would look like: > -- QUOTE -- > For all input files passed to compiler: > If extension is .o: > Use llc to generate .s file > Add this filename to some collection > Else if extension is .a: > Extract contents of this archive > Use llc on each file to generate .s file > Add each filename to the collection > End if > End for > Retrieve all `.s' filenames and pass them all to gcc or gfortran > -- UNQUOTE -- > But the part that deals with `.a' files is a bit ugly. llvm-ld handles the > archive (.a) files without any manual extraction but I fear that because > llvm-ld is not a full-featured linker, I might run into a wall because of > incompatible options between gfortran/gcc and llvm-ld. > Ashay > > On Mon, Sep 12, 2011 at 3:38 PM, Dmitry N. Mikushin <maemarcus at gmail.com> > wrote: >> >> Sorry, at what step do you need archive? llc emits binary, it does not >> perform any linking, thus it does not need anything except the input >> bytecode file. Then during linking you can link whatever archives of >> binaries you want. >> >> 2011/9/13 Ashay Rane <ashay.rane at tacc.utexas.edu>: >> > Thats correct. But using llc becomes a problem when I have archives (.a >> > files). I could, in theory, extract its contents to a tempdir and then >> > use >> > llc and link but just wondering if there is a more elegant solution. >> > Ashay >> > >> > On Mon, Sep 12, 2011 at 3:00 PM, Dmitry N. Mikushin >> > <maemarcus at gmail.com> >> > wrote: >> >> >> >> Ashay, >> >> >> >> If I understand correctly, in hw.o you would have llvm bytecode, while >> >> linker expects regular object binary. Probably first you need to emit >> >> asm out of bytecode using llc? >> >> >> >> - D. >> >> >> >> 2011/9/12 Ashay Rane <ashay.rane at tacc.utexas.edu>: >> >> > Hello, >> >> > Sorry for the late reply. Using dragonegg worked well, thanks all! >> >> > Just as a note... I had to use llvm-ld during the link step because >> >> > gfortran >> >> > could not link bitcode. Here's an example of the error shown when >> >> > using >> >> > gfortran instead of llvm-ld: >> >> > $ ${GCC_4_5_0}/bin/gfortran hw.f -c >> >> > -fplugin=${DRAGONEGG_PLUGIN}/dragonegg.so -o hw.o -flto -emit-llvm -S >> >> > $ ${LLVM_2_9}/bin/opt -mem2reg hw.o -o hw.o >> >> > $ ${GCC_4_5_0}/bin/gfortran >> >> > >> >> > >> >> > -fplugin=${DRAGONEGG_PLUGIN}/dragonegg.so ${GCC_4_5_0}/lib64/libgfortran.a >> >> > hw.o -o hw >> >> > hw.o: file not recognized: File format not recognized >> >> > collect2: ld returned 1 exit status >> >> > $ file hw.o >> >> > hw.o: data >> >> > Instead, using llvm-ld: >> >> > $ ${LLVM_2_9}/bin/llvm-ld -native hw.o -o hw >> >> > ${GCC_4_5_0}/lib64/libgfortran.a -lm >> >> > llvm-gcc had the gold plugin. I wonder if there is any equivalent of >> >> > that >> >> > for dragonegg to be able to compile bitcode and native object code in >> >> > a >> >> > transparent manner. >> >> > Thanks again! >> >> > Ashay >> >> > >> >> > On Wed, Aug 31, 2011 at 4:29 PM, Anton Korobeynikov >> >> > <anton at korobeynikov.info> wrote: >> >> >> >> >> >> Hello >> >> >> >> >> >> > I am not very familiar with Fortran programs. I saw a few programs >> >> >> > that >> >> >> > had >> >> >> > a "MAIN" subroutine defined, some others that did not. Am I >> >> >> > missing >> >> >> > something while compiling the code? Is there a different way to >> >> >> > compile >> >> >> > bitcode (from Fortran programs) to a native binary? >> >> >> For Fortran MAIN is indeed something similar to C main, but not >> >> >> exactly the same. >> >> >> You have to link the runtime library (libgfortran.a) in order to get >> >> >> "proper" main, mak sure all stuff is initialized properly, etc. >> >> >> >> >> >> -- >> >> >> With best regards, Anton Korobeynikov >> >> >> Faculty of Mathematics and Mechanics, Saint Petersburg State >> >> >> University >> >> > >> >> > >> >> > _______________________________________________ >> >> > LLVM Developers mailing list >> >> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > >> >> > >> > >> > > >
No, I am running the LLVM pass at the compilation step. So by the time I reach the link step, the transformed bitcode has been generated. Ashay On Mon, Sep 12, 2011 at 4:12 PM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote:> I see. And what's the purpose for outputting bitcode into *.o and *.a > files? Do you want to perform an LLVM pass on linking step? > > 2011/9/13 Ashay Rane <ashay.rane at tacc.utexas.edu>: > > Hmm.. I didn't explain the problem completely last time. I am creating a > > drop-in replacement for gcc and gfortran that runs an additional pass on > the > > bitcode before generating the native binary. Here's whats happening: If > the > > source code compilation process builds a static library (.a archive > file), I > > need a means to link the `.a' file statically into the application. So if > > the original statement was: > > gfortran file.o -L somedir -lmylib -o file > > then my modified compilation process would have to deal with file.o and > > libmylib.a to generate the binary `file'. Now, all files essentially > contain > > bitcode (file.o and object files inside libmylib.a). So the pseudo-code > > would look like: > > -- QUOTE -- > > For all input files passed to compiler: > > If extension is .o: > > Use llc to generate .s file > > Add this filename to some collection > > Else if extension is .a: > > Extract contents of this archive > > Use llc on each file to generate .s file > > Add each filename to the collection > > End if > > End for > > Retrieve all `.s' filenames and pass them all to gcc or gfortran > > -- UNQUOTE -- > > But the part that deals with `.a' files is a bit ugly. llvm-ld handles > the > > archive (.a) files without any manual extraction but I fear that because > > llvm-ld is not a full-featured linker, I might run into a wall because of > > incompatible options between gfortran/gcc and llvm-ld. > > Ashay > > > > On Mon, Sep 12, 2011 at 3:38 PM, Dmitry N. Mikushin <maemarcus at gmail.com > > > > wrote: > >> > >> Sorry, at what step do you need archive? llc emits binary, it does not > >> perform any linking, thus it does not need anything except the input > >> bytecode file. Then during linking you can link whatever archives of > >> binaries you want. > >> > >> 2011/9/13 Ashay Rane <ashay.rane at tacc.utexas.edu>: > >> > Thats correct. But using llc becomes a problem when I have archives > (.a > >> > files). I could, in theory, extract its contents to a tempdir and then > >> > use > >> > llc and link but just wondering if there is a more elegant solution. > >> > Ashay > >> > > >> > On Mon, Sep 12, 2011 at 3:00 PM, Dmitry N. Mikushin > >> > <maemarcus at gmail.com> > >> > wrote: > >> >> > >> >> Ashay, > >> >> > >> >> If I understand correctly, in hw.o you would have llvm bytecode, > while > >> >> linker expects regular object binary. Probably first you need to emit > >> >> asm out of bytecode using llc? > >> >> > >> >> - D. > >> >> > >> >> 2011/9/12 Ashay Rane <ashay.rane at tacc.utexas.edu>: > >> >> > Hello, > >> >> > Sorry for the late reply. Using dragonegg worked well, thanks all! > >> >> > Just as a note... I had to use llvm-ld during the link step because > >> >> > gfortran > >> >> > could not link bitcode. Here's an example of the error shown when > >> >> > using > >> >> > gfortran instead of llvm-ld: > >> >> > $ ${GCC_4_5_0}/bin/gfortran hw.f -c > >> >> > -fplugin=${DRAGONEGG_PLUGIN}/dragonegg.so -o hw.o -flto -emit-llvm > -S > >> >> > $ ${LLVM_2_9}/bin/opt -mem2reg hw.o -o hw.o > >> >> > $ ${GCC_4_5_0}/bin/gfortran > >> >> > > >> >> > > >> >> > > -fplugin=${DRAGONEGG_PLUGIN}/dragonegg.so ${GCC_4_5_0}/lib64/libgfortran.a > >> >> > hw.o -o hw > >> >> > hw.o: file not recognized: File format not recognized > >> >> > collect2: ld returned 1 exit status > >> >> > $ file hw.o > >> >> > hw.o: data > >> >> > Instead, using llvm-ld: > >> >> > $ ${LLVM_2_9}/bin/llvm-ld -native hw.o -o hw > >> >> > ${GCC_4_5_0}/lib64/libgfortran.a -lm > >> >> > llvm-gcc had the gold plugin. I wonder if there is any equivalent > of > >> >> > that > >> >> > for dragonegg to be able to compile bitcode and native object code > in > >> >> > a > >> >> > transparent manner. > >> >> > Thanks again! > >> >> > Ashay > >> >> > > >> >> > On Wed, Aug 31, 2011 at 4:29 PM, Anton Korobeynikov > >> >> > <anton at korobeynikov.info> wrote: > >> >> >> > >> >> >> Hello > >> >> >> > >> >> >> > I am not very familiar with Fortran programs. I saw a few > programs > >> >> >> > that > >> >> >> > had > >> >> >> > a "MAIN" subroutine defined, some others that did not. Am I > >> >> >> > missing > >> >> >> > something while compiling the code? Is there a different way to > >> >> >> > compile > >> >> >> > bitcode (from Fortran programs) to a native binary? > >> >> >> For Fortran MAIN is indeed something similar to C main, but not > >> >> >> exactly the same. > >> >> >> You have to link the runtime library (libgfortran.a) in order to > get > >> >> >> "proper" main, mak sure all stuff is initialized properly, etc. > >> >> >> > >> >> >> -- > >> >> >> With best regards, Anton Korobeynikov > >> >> >> Faculty of Mathematics and Mechanics, Saint Petersburg State > >> >> >> University > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > 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/20110912/b547aea4/attachment.html>