[LLVMdev] llvm-gfortran problems

[Ashay Rane]

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>