[LLVMdev] llvm-gfortran problems

[Dmitry N. Mikushin]

If all llvm passes are compile-time, then I think nothing limits you
from invoking llc for each standalone object: source -> bitcode ->
binary object. And binary objects will be generated before packing
them into static libraries. I don't see any problem.

2011/9/13 Ashay Rane <ashay.rane at tacc.utexas.edu>:
> 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
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>