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/dd52e2ba/attachment.html>
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 >> > >> > > >
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>