Displaying 9 results from an estimated 9 matches similar to: "Using influence plots and obtaining id numbers"
2011 Feb 22
1
[LLVMdev] llvm-gcc4.2 bootstrap broken?
On Mon, Feb 21, 2011 at 03:58:19PM -0800, Eric Christopher wrote:
>
> On Feb 19, 2011, at 11:25 AM, Jack Howarth wrote:
>
> > Is anyone able to bootstrap llvm-gcc42 svn on x86_64-apple-darwin10? Currently it is
> > failing here with...
>
> It was broken. I think I've fixed it in reverting 125960.
>
> -eric
Eric,
The llvm-gcc42 bootstrap is fixed in
2010 Sep 20
1
[LLVMdev] Polyhedron 2005 regressions
Comparing the Polyhedron 2005 benchmark results for gfortran from
llvm-gcc-4.2 of April 7th, 2010 and September 18th, 2010 (from
the rc2 2.8 release branch), we seem to be regressing in performance
for this release....
================================================================================
Date & Time : 7 Apr 2010 22:24:16
Test Name : llvm_gfortran_lin_p4
Compile Command :
2010 Apr 08
1
[LLVMdev] darwin llvm-gfortran Polyhedron 2005 results
On Thu, Apr 08, 2010 at 08:45:48AM -0700, Bob Wilson wrote:
> [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
2010 Apr 08
0
[LLVMdev] darwin llvm-gfortran Polyhedron 2005 results
On Apr 7, 2010, at 8:41 PM, Jack Howarth wrote:
> 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
2010 Apr 08
2
[LLVMdev] darwin llvm-gfortran Polyhedron 2005 results
On Apr 8, 2010, at 8:45 AMPDT, Bob Wilson wrote:
> [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.
2010 Apr 08
3
[LLVMdev] 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)...
================================================================================
Date & Time : 7 Apr 2010 22:24:16
Test Name : llvm_gfortran_lin_p4
Compile Command : llvm-gfortran -ffast-math -funroll-loops -msse3
2010 Apr 08
0
[LLVMdev] darwin llvm-gfortran Polyhedron 2005 results
[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
2010 Apr 08
3
[LLVMdev] darwin llvm-gfortran Polyhedron 2005 results
On Wed, Apr 07, 2010 at 09:54:36PM -0700, Chris Lattner wrote:
>
> On Apr 7, 2010, at 8:41 PM, Jack Howarth wrote:
>
> > 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
2008 Oct 31
6
[LLVMdev] polyhedron 2005 results for llvm svn
I am finding with the patch that all of the Polyhedron 2005
benchmarks pass on i686-apple-darwin9. Could someone clarify the
regression rules for releases? Not building a secondary language
on a primary target is usually considered a P1 regression for
FSF gcc. Not doing so here gives one the impression that llvm.org
isn't playing by the same rules. No one is ever going to want to
use these