darwin llvm-gfortran Polyhedron 2005 results

Building the current release 2.7 branch on x86_64-apple-darwin10
with r81455 reverted, I get the following Polyhedron 2005 benchmark
results (with no test failures)...

Building the current release 2.7 branch on x86_64-apple-darwin10
with r81455 reverted, I get the following Polyhedron 2005 benchmark
results (with no test failures)...

Very nice! A 14% speedup on a benchmark we don't tune for isn't bad. I imagine that there are several easy wins you could get on it if you were interested in analyzing the performance. I don't think that anyone has done *any* llvm-gfortran perf work.

-Chris

> Building the current release 2.7 branch on x86_64-apple-darwin10
> with r81455 reverted, I get the following Polyhedron 2005 benchmark
> results (with no test failures)...

Very nice! A 14% speedup on a benchmark we don't tune for isn't bad. I imagine that there are several easy wins you could get on it if you were interested in analyzing the performance. I don't think that anyone has done *any* llvm-gfortran perf work.

-Chris

Chris,
   Slightly off-topic, I've just added a fsf-gdb package to fink to provide darwin
users with a gdb 7.1 release for i386-apple-darwin/x86_64-apple-darwin. This will
help with debugging issues in gfortran since I believe gdb 6.8 had relatively
poor support for certain areas of gfortran's code generation.
         Jack

> Building the current release 2.7 branch on x86_64-apple-darwin10
> with r81455 reverted, I get the following Polyhedron 2005 benchmark
> results (with no test failures)...

Very nice! A 14% speedup on a benchmark we don't tune for isn't bad. I imagine that there are several easy wins you could get on it if you were interested in analyzing the performance. I don't think that anyone has done *any* llvm-gfortran perf work.

-Chris

Chris,
   How essential is r81455 to the llvm-gcc4.2-2.7 release? Can we regress it
out for 2.7? I've tried all of the suggestions in...

http://llvm.org/bugs/show_bug.cgi?id=6778

from Duncan for moving va_opt into darwin.c as an extern. While this
works at first glance, it destablizes the parallel make. Regressing r81455
doesn't appear to cause any problems.
                  Jack

[CCing Dale since this was his change, not mine]

The change in 81455 fixes a compiler crash. It doesn't happen very often, but I can't imagine we would want to back that out. Fixing it would be a more reasonable solution. From a quick look at it, the problem is that gcc/config/darwin-c.c is registering va_opt for GC. When you build for Fortran, darwin-c.o is not linked so the GC gets confused somehow.

[CCing Dale since this was his change, not mine]

The change in 81455 fixes a compiler crash. It doesn't happen very often, but I can't imagine we would want to back that out. Fixing it would be a more reasonable solution. From a quick look at it, the problem is that gcc/config/darwin-c.c is registering va_opt for GC. When you build for Fortran, darwin-c.o is not linked so the GC gets confused somehow.

Bob,
    Duncan suggested moving va_opt into darwin.o and changing the declaration from static to
extern in darwin-c.o. I have tried that here...

http://llvm.org/bugs/attachment.cgi?id=4652

in various forms. While the change seems to work for
a simple make, it breaks parallel builds...

http://llvm.org/bugs/show_bug.cgi?id=6778#c17

Do you have any suggestions for a change to the fortran build
to solve this? We can't link in darwin-c.o of course, but would
it make sense to have fortran declare it's own static copy of
va_opt somewhere?
              Jack

Dale?

My only involvement with this was adding the missing "LLVM LOCAL" markers....

[CCing Dale since this was his change, not mine]

The change in 81455 fixes a compiler crash. It doesn't happen very often, but I can't imagine we would want to back that out. Fixing it would be a more reasonable solution. From a quick look at it, the problem is that gcc/config/darwin-c.c is registering va_opt for GC. When you build for Fortran, darwin-c.o is not linked so the GC gets confused somehow.

This is the first I was aware this patch broke anything; nobody cc'd me on the bugzilla, and I don't normally pay attention to Fortran mail.

We definitely don't want to revert 81455; the bug caused a crash building something that's part of MacOS, and yes, that's more important than Fortran. But it should be possible to get Fortran to build. I would think the right idea is to change the build so that either darwin-c.o gets linked in (theoretically wrong but it should work), or (better) gt_gcc–r_gt_darwin_c_h is not referenced in Fortran. It appears to be configured into gtype-fortran.h, which is generated during the build, so the thing would be to get it not to go in there....I'm not that expert with the GC mechanism, but I can play around a little....

> [CCing Dale since this was his change, not mine]
>
> The change in 81455 fixes a compiler crash. It doesn't happen very often, but I can't imagine we would want to back that out. Fixing it would be a more reasonable solution. From a quick look at it, the problem is that gcc/config/darwin-c.c is registering va_opt for GC. When you build for Fortran, darwin-c.o is not linked so the GC gets confused somehow.

This is the first I was aware this patch broke anything; nobody cc'd me on the bugzilla, and I don't normally pay attention to Fortran mail.

We definitely don't want to revert 81455; the bug caused a crash building something that's part of MacOS, and yes, that's more important than Fortran. But it should be possible to get Fortran to build. I would think the right idea is to change the build so that either darwin-c.o gets linked in (theoretically wrong but it should work), or (better) gt_gcc–r_gt_darwin_c_h is not referenced in Fortran. It appears to be configured into gtype-fortran.h, which is generated during the build, so the thing would be to get it not to go in there....I'm not that expert with the GC mechanism, but I can play around a little....

Dale,
   Thanks. You might also look at Duncan's comment at...

http://llvm.org/bugs/show_bug.cgi?id=6778#c20

about the fact that darwin-c.o seems to have multiple
entries in config/t-darwin.
                 Jack

There seems to be no precedent for a GC-using file that's both target and language dependent.
c-config-lang.in looks OK for this case, although it wouldn't generalize. This seems to work for me, does it look OK for other environments?

patch.txt (1.16 KB)