search for: ldecodes

Hello; I am still having problems making the llvm-test suite and running command like "make TEST=libcalls report" is giving me unexpected output. So first I tried the following - 1. I built and installed llvm(3.0) under Ubuntu 11.10 (using the ./configure script found under llvm source, and then make and make install). While configuring, I gave --prefix as a directory where I would

Hello; I was able to build and install llvm(3.0) under Ubuntu 11.10 (using the ./configure script found under llvm source, and then make and make install). While configuring, I gave --prefix as a directory where I would like llvm to be installed. I did not give --with-llvmgccdir and the --enable-optimized argument to configure. Because 3.0 doesn't come with llvmgcc source/binaries and I

On 03/16/2011 03:39 PM, Jakob Stoklund Olesen wrote: > On Mar 16, 2011, at 6:19 AM, José Fonseca wrote: > > >> On Tue, 2011-03-15 at 20:29 -0700, Jakob Stoklund Olesen wrote: >> >>> On Mar 15, 2011, at 4:15 PM, jfonseca at vmware.com wrote: >>> >>> >>>> This series of patches address several issues causing memory usage

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

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

On Mar 24, 2011, at 7:23 AM, José Fonseca wrote: >>> >> I normally use 403.gcc, but if you don't have SPEC sources, these tests in the nightly test suite take a while to compile: >> >> MultiSource/Applications/ClamAV >> MultiSource/Applications/JM/ldecod >> MultiSource/Applications/JM/lencod >> MultiSource/Applications/SPASS >>

On 03/24/2011 03:30 PM, Jakob Stoklund Olesen wrote: > > On Mar 24, 2011, at 7:23 AM, José Fonseca wrote: >>>> >>> I normally use 403.gcc, but if you don't have SPEC sources, these >>> tests in the nightly test suite take a while to compile: >>> >>> MultiSource/Applications/ClamAV >>> MultiSource/Applications/JM/ldecod

Did something change with exception handling recently? A bunch of lit bots are showing slower compile times for many tests. Ciao, Duncan. On 20/06/12 07:53, llvm-testresults at cs.uiuc.edu wrote: > > lab-mini-03__O0-g__clang_DEV__x86_64 test results > <http://llvm.org/perf/db_default/v4/nts/1283?compare_to=1278&baseline=999> > > Run Order Start Time Duration >

Perhaps you noticed that LLVM gained a new optimizing register allocator yesterday (r130568). Linear scan is going away, and RAGreedy is the new default for optimizing builds. Hopefully, you noticed because your binaries were suddenly 2% smaller and 10% faster*. Some noticed because LLVM started crashing or miscompiling their code. Greedy replaces a fairly big chunk of the code generator, so

On Mar 16, 2011, at 6:19 AM, José Fonseca wrote: > On Tue, 2011-03-15 at 20:29 -0700, Jakob Stoklund Olesen wrote: >> On Mar 15, 2011, at 4:15 PM, jfonseca at vmware.com wrote: >> >>> This series of patches address several issues causing memory usage to grow >>> indefinetely on a long lived process. >> >> Thanks for working on this. >>

Nothing that I'm aware of has changed with EH. Is it possible to bisect the problem? -bw On Jun 20, 2012, at 12:38 AM, Duncan Sands <baldrick at free.fr> wrote: > Did something change with exception handling recently? A bunch of lit bots are > showing slower compile times for many tests. > > Ciao, Duncan. > > On 20/06/12 07:53, llvm-testresults at cs.uiuc.edu

Hi Bill, > Nothing that I'm aware of has changed with EH. Is it possible to bisect the problem? I don't see any relevant LLVM changes, so I guess clang C++ compilation slowed down due to some clang changes. I'm not going to investigate this. Ciao, Duncan. > > -bw > > On Jun 20, 2012, at 12:38 AM, Duncan Sands <baldrick at free.fr> wrote: > >> Did

A big compile time regression. Any ideas? Ciao, Duncan. On 22/07/11 19:13, llvm-testresults at cs.uiuc.edu wrote: > > bwilson__llvm-gcc_PROD__i386 nightly tester results > > URL http://llvm.org/perf/db_default/simple/nts/253/ > Nickname bwilson__llvm-gcc_PROD__i386:4 > Name curlew.apple.com > > Run ID Order Start Time End Time > Current 253 0 2011-07-22 16:22:04

On Tue, 2011-03-15 at 20:29 -0700, Jakob Stoklund Olesen wrote: > On Mar 15, 2011, at 4:15 PM, jfonseca at vmware.com wrote: > > > This series of patches address several issues causing memory usage to grow > > indefinetely on a long lived process. > > Thanks for working on this. > > Did you measure the performance impact of these changes? I tracked performance

On Jul 5, 2012, at 1:33 AM, Duncan Sands wrote: > Hi Bill, > >> Nothing that I'm aware of has changed with EH. Is it possible to bisect the problem? > > I don't see any relevant LLVM changes, so I guess clang C++ compilation slowed > down due to some clang changes. I'm not going to investigate this. > Crumbs. John, Do you know of anything that went into

I created the 1.9 release branch last night. As a reminder, please do not check in any code changes to the release branch. Please send me email if you have changes that need to be merged into the release branch. To check out the release branch: cvs -d <CVS Repository> co -r release_19 llvm cvs -d <CVS Repository> co -r release_19 llvm-test cvs -d <CVS Repository> co -r

Hi, Over the past six months, a MemorySSA-backed DSE implementation has been added to LLVM and it now covers almost all cases the existing DSE implementation does, plus adding a major new capability: eliminating stores across basic blocks. Thanks everyone involved with reviews, testing & patches! I think now would be a good time to start working towards switching to use MemorySSA-backed DSE

On Jul 24, 2011, at 3:02 AM, Duncan Sands wrote: > A big compile time regression. Any ideas? > > Ciao, Duncan. False alarm. For some reason that I have not yet been able to figure out, these tests run significantly more slowly when I run them during the daytime, which I did for that run. I checked a few of the worst regressions reported here and they all recovered in subsequent

Tanya, Here's the results for GNU/Linux, 2.6.18-1.2200.fc5smp (Fedora Core 5) HIGH LEVEL COMMENTS * The llvm-1.9.tar.gz file unpacks to a dir named "llvm". Shouldn't that be llvm-1.9? * LLVM was built in Release mode in all cases * I don't think this is ready for release. In particular the llvm-gcc4 binary seg faults on FC 5 for most of llvm-test programs. *

LLVMers, The LLVM 1.9 Prerelease is available for testing: http://llvm.org/prereleases/1.9/ If anyone can spare some time, please download the appropriate tarballs for your platform and test the release (at least with make check). I'd also appreciate any documentation reviews. Please note that llvm-gcc3 on x86 may not have a clean dejagnu run. You should see one XPASS for