On 9/1/06, Chris Lattner <sabre at nondot.org> wrote:> On Fri, 1 Sep 2006, Michael McCracken wrote: > > I wanted to know if I should submit patches with comments around them > > like the "APPLE LOCAL LLVM" ones that mark the LLVM-only changes to > > the tree. I'd like to make it as easy as possible to apply these, so > > let me know any rules I should be following. > > Don't worry about them. The rules for use are finicky and they are easy > to add. I'll add them to any patches. Thanks!OK, thanks - I'll just keep my patches clean and let you worry about the markers. [snip]> This is crashing because make_decl_rtl is an RTL backend specific > function. I haven't looked at the callsite but you probably want > something like this: > > #ifndef ENABLE_LLVM > make_decl_rtl (olddecl); > #else > make_decl_llvm (olddecl); > #endif > > make_decl_rtl is also sometimes called implicitly by "DECL_RTL". Any uses > of DECL_RTL need to be replaced with DECL_LLVM. If you have questions on > a particular use, I'd be happy to help.OK, that makes sense. I should have been able to figure that out myself, huh :\ There are only a few cases of make_decl_rtl in the fortran code, so I replaced them all as you suggested. It seemed straightforward in each case. I've attached a patch for the changes to the make_decl_rtl callsites, at the end. Now f951 doesn't crash when compiling, but still can't compile the libgfortran files. It now finds some syntax errors in a generated file that's part of the intrinsics library. It does compile a very simple test program. It generates reasonable-looking LLVM code, except for using "MAIN__" instead of "main" for the main procedure. I suspect that may be solved by libgfortran once that's working. After editing that, the simple example runs in lli up to the linking errors where the libgfortran routines are called. I'm looking into the errors, and I'll update the list on any progress. Index: gcc/fortran/f95-lang.c ==================================================================--- gcc/fortran/f95-lang.c (revision 160) +++ gcc/fortran/f95-lang.c (working copy) @@ -713,7 +713,11 @@ TREE_PUBLIC (decl) = 1; if (library_name) SET_DECL_ASSEMBLER_NAME (decl, get_identifier (library_name)); +#ifndef ENABLE_LLVM make_decl_rtl (decl); +#else + make_decl_llvm (decl); +#endif pushdecl (decl); DECL_BUILT_IN_CLASS (decl) = class; DECL_FUNCTION_CODE (decl) = function_code; Index: gcc/fortran/trans-decl.c ==================================================================--- gcc/fortran/trans-decl.c (revision 160) +++ gcc/fortran/trans-decl.c (working copy) @@ -1334,7 +1334,11 @@ } /* Create RTL for function definition. */ +#ifndef ENABLE_LLVM make_decl_rtl (fndecl); +#else + make_decl_llvm (fndecl); +#endif init_function_start (fndecl); @@ -2472,8 +2476,11 @@ current_function_decl = fndecl; rest_of_decl_compilation (fndecl, 1, 0); - +#ifndef ENABLE_LLVM make_decl_rtl (fndecl); +#else + make_decl_llvm (fndecl); +#endif init_function_start (fndecl); Thanks, -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/
On 9/1/06, Michael McCracken <michael.mccracken at gmail.com> wrote:> On 9/1/06, Chris Lattner <sabre at nondot.org> wrote: > > On Fri, 1 Sep 2006, Michael McCracken wrote:[snip]> Now f951 doesn't crash when compiling, but still can't compile the > libgfortran files. It now finds some syntax errors in a generated file > that's part of the intrinsics library.That was a problem with an incomplete build. libgfortran now compiles without error (although not without warnings...). I'm now testing on a couple of simple examples. gfortran+llvm compiles my simplest example into native code correctly. There are some issues with a more complicated example, but at least this is a start. I can generate llvm asm and bytecode using --emit-llvm -[S,c], but I can't run the resulting files in lli. I am guessing that I would need to compile libgfortran as bytecode and link it with llvm-link to get that to work, right? I don't need to do that just yet, although I will want to be able to run that way eventually. I also noticed that there doesn't seem to be a test suite for gfortran in the source distribution. I'm going to start with the updated version of the NIST F77 test suite (updated to conform to F95) that's available from fortran-2000.com. Thanks, -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/
On Fri, 1 Sep 2006, Michael McCracken wrote:> I've attached a patch for the changes to the make_decl_rtl callsites, > at the end.Sounds good, I'll apply the patch on monday. -Chris> Now f951 doesn't crash when compiling, but still can't compile the > libgfortran files. It now finds some syntax errors in a generated file > that's part of the intrinsics library. > > > It does compile a very simple test program. It generates > reasonable-looking LLVM code, except for using "MAIN__" instead of > "main" for the main procedure. I suspect that may be solved by > libgfortran once that's working. After editing that, the simple > example runs in lli up to the linking errors where the libgfortran > routines are called. > > I'm looking into the errors, and I'll update the list on any progress. > > Index: gcc/fortran/f95-lang.c > ==================================================================> --- gcc/fortran/f95-lang.c (revision 160) > +++ gcc/fortran/f95-lang.c (working copy) > @@ -713,7 +713,11 @@ > TREE_PUBLIC (decl) = 1; > if (library_name) > SET_DECL_ASSEMBLER_NAME (decl, get_identifier (library_name)); > +#ifndef ENABLE_LLVM > make_decl_rtl (decl); > +#else > + make_decl_llvm (decl); > +#endif > pushdecl (decl); > DECL_BUILT_IN_CLASS (decl) = class; > DECL_FUNCTION_CODE (decl) = function_code; > Index: gcc/fortran/trans-decl.c > ==================================================================> --- gcc/fortran/trans-decl.c (revision 160) > +++ gcc/fortran/trans-decl.c (working copy) > @@ -1334,7 +1334,11 @@ > } > > /* Create RTL for function definition. */ > +#ifndef ENABLE_LLVM > make_decl_rtl (fndecl); > +#else > + make_decl_llvm (fndecl); > +#endif > > init_function_start (fndecl); > > @@ -2472,8 +2476,11 @@ > current_function_decl = fndecl; > > rest_of_decl_compilation (fndecl, 1, 0); > - > +#ifndef ENABLE_LLVM > make_decl_rtl (fndecl); > +#else > + make_decl_llvm (fndecl); > +#endif > > init_function_start (fndecl); > > > Thanks, > -mike > >-Chris -- http://nondot.org/sabre/ http://llvm.org/
On Fri, 1 Sep 2006, Michael McCracken wrote:> I'm now testing on a couple of simple examples. > gfortran+llvm compiles my simplest example into native code correctly. > There are some issues with a more complicated example, but at least > this is a start.Cool, you're making great progress.> I can generate llvm asm and bytecode using --emit-llvm -[S,c], but I > can't run the resulting files in lli. I am guessing that I would need > to compile libgfortran as bytecode and link it with llvm-link to get > that to work, right? I don't need to do that just yet, although I will > want to be able to run that way eventually.If LLI is your goal, there are two possibilities: you can either compile the runtime library to .bc file which you statically llvm-link in, or you can compile it to a .so file, which you ask lli to load, like this: $ lli -load myruntimelib.so myprogram.bc <args> -Chris -- http://nondot.org/sabre/ http://llvm.org/