similar to: [LLVMdev] LLVM benchmarks against GCC

On Tue, 27 Apr 2004, [koi8-r] "Valery A.Khamenya[koi8-r] " wrote: > i was thinking that this question was not good > right after relese 1.0, but now perhaps it is OK... > if not, then I am sorry. You could always ask, it's just that the answer changes over time. :) > So, what about current status of benchmarks? > I mean comparison to gcc. It's slowly getting

> Be careful comparing these numbers. I see that we have a 23x speedup > today over GCC on the "burg" test, but we go from 0.093 -> 0.004s. :) > The shorter the test runs get, the more noisy they get, so unfortunately > we're not getting a realistic 23x speedup here. ;-) > [...] > These are even more dubious. In particular, only the first 6 rows contain >

On Fri, 30 Apr 2004, [koi8-r] "Valery A.Khamenya[koi8-r] " wrote: > > This one is just noise, if you look today it's 1.0's straight across the > > board. Also note that the test runs for 0.003 seconds, which is the > > resolution of the time command on the system the program is being run on: > > this is not a good test for checking performance. :) >

> > Okay, I changed the C backend to emit syntactic loops around the real > loops, and it seems to make a big difference. LLVM now generates this > code (note that the actual loop is not actually responsible for control > flow, it's unreachable): > > ... which is exactly what we want. Patrick, I would appreciate it if > you > could rerun your tests on PPC and let

Hi all i took a look into LLVM benchmarks from nightly tester and ran Shootout tests on my own. Below go just few outlines. 1. results on my AMD AthlonXP and Xeon used by LLVM team are different sometime. In particular, both Shootout and Shootout-C++ show great speed up with LLVM (in comparison to GCC) on ackerman test on my AthlonXP. But here:

On Sat, 19 Jun 2004, [koi8-r] "Valery A.Khamenya[koi8-r] " wrote: > i took a look into LLVM benchmarks from nightly tester and > ran Shootout tests on my own. Below go just few outlines. > > 1. results on my AMD AthlonXP and Xeon used by LLVM > team are different sometime. In particular, both Shootout > and Shootout-C++ show great speed up with LLVM (in >

Dale, Thanks for reviewing this. I have some newbie questions regarding the test-suite for you or anyone: I'm trying to run the test-suite as described in the "LLVM Testing Infrastructure Guide" on a Ubuntu x86 64 bit system. Initially I ran into problems with missing tools like yacc, which I fixed as I went along until the make at the test-suite level completed. However, I get

CBE is fairly broken everywhere AFAIK, don't worry about it. Most of the JIT failures are in tests that exercise exception handling. Not sure if that is supposed to work in your environment, it works in some JITs and not others. The LLC failures are cause for concern. On Aug 30, 2010, at 10:59 AMPDT, John Thompson wrote: > Dale, > > Thanks for reviewing this. > > I have

Dale, I took a closer look at the first llc failure, initp1. Looking at the initp1.llc file in gdb, it appears that the statically constructed objects without the init_priority attribute are being constructed before those with it, though the test seems to expect the opposite. The initp1.llc.s file seems to have the .ctors table in the right order, but the _init code is reading the table in

On Aug 30, 2010, at 3:11 PMPDT, John Thompson wrote: > Dale, > > I took a closer look at the first llc failure, initp1. Looking at > the initp1.llc file in gdb, it appears that the statically > constructed objects without the init_priority attribute are being > constructed before those with it, though the test seems to expect > the opposite. > > The

On Sep 1, 2010, at 11:03 AMPDT, John Thompson wrote: > I'm close to confirming that I get the equivalent results from the > test-suite with my changes, compared to a fresh tree, on a Linux x86 > 64 bit box. > > When that is the case, may I check in my current changes for the > LLVM side? In principle, yes, I'd like to rereview if it's changed. > My

I'm close to confirming that I get the equivalent results from the test-suite with my changes, compared to a fresh tree, on a Linux x86 64 bit box. When that is the case, may I check in my current changes for the LLVM side? My preference is to develop the mult-alt support incrementally, rather than one big check-in, as I get nervous sitting on a lot of changes for a long time. I feel this

Actually the 2.8 fork is coming up tomorrow and I'm thinking maybe we should wait until after that. Is this something you really want to get in 2.8? On Sep 1, 2010, at 6:29 PMPDT, John Thompson wrote: > Dale, > > Thanks. It's not changed, but I've enclosed a fresh patch against > today's trunk. > However, I'm seeing 28 unexpected failing tests in

Hi Tanya, Here's my second attempt on Fedora Core 5. The changes this time are: 1. Using GCC 4.0.3 as the compiler 2. Building everything from source (no pre-built binaries used) BUILD LLVM WITH GCC 4.0.3 * No issues, just the usual warnings. BUILD LLVM-GCC WITH GCC 4.0.3 * No issues RUN LLVM-TEST WITH GCC 4.0.3 * The following failures were encountered. Some of them are

Dale, Thanks. It's not changed, but I've enclosed a fresh patch against today's trunk. However, I'm seeing 28 unexpected failing tests in llvm/test on x86 Linux 64 today. But it's the same on an unmodified tree, so I guess I'm still okay. It passed at one point for me with these changes. -John On Wed, Sep 1, 2010 at 5:04 PM, Dale Johannesen <dalej at apple.com>

On May 6, 2004, at 12:01 AM, Chris Lattner wrote: > On Wed, 5 May 2004, Patrick Flanagan wrote: >>>> and I'm not convinced that GCC is doing a very good job (ie, without >>>> syntactic loops). >>> >>> Yup, this is EXACTLY what is going on. >> >> Interesting. Now that you mention it, I do recall thinking the loops >> that llvm

I'm having some trouble using bugpoint with newer version of gcc (bugpoint debug output below). I looked into the "conflicting type for malloc" problem and it doesn't seem easy to solve due to the unknown size of size_t (see LowerAllocations.cpp). The "void main()" problem is probably a result of this test being converted from Fortran. I'll have to dig into

On Tue, 4 May 2004, Chris Lattner wrote: > On Tue, 4 May 2004, Chris Lattner wrote: > > I suspect that a large reason that LLVM does worst than a native C > > compiler with the CBE+GCC is that LLVM generates very low-level C code, > > and I'm not convinced that GCC is doing a very good job (ie, without > > syntactic loops). > > Yup, this is EXACTLY what is

Hi Tanya, I've been checking the state of the various llvm-test failures on X86/Linux with GCC 3.4.6 and llvm-gcc4. I haven't finished this, but I thought the following might be useful for other people that are testing the release on Linux. Each group of failing tests below is followed by a comment about why its failing. llc /MultiSource/Applications/oggenc/oggenc jit

Everything builds fine on sparc. The configure script needs to be fixed though (see previous email). Sparc testing results: make check: # of expected passes 1189 # of expected failures 34 Regressions Single Source: None New Failures Single Source (new tests): 2005-05-12-Int64ToFP: llc,jit Regressions MultiSource: Applications/d/make_dparser: llc, cbe, jit