similar to: [LLVMdev] POST MORTEM: llvm-test changes

Configure gives me these errors on FreeBSD. I'm proceding with the build anyway to see what happens. Don't worry :) It'll only take about 2.5 hours instead of 30+ now. install: ../test/Programs/Makefile does not exist config.status: executing test/Programs/Makefile.programs commands install: ../test/Programs/Makefile.programs does not exist config.status: executing

Jeff, Actually, that was my fault. I forgot to remove the non-existent directories from the configure.ac file. That's done and committed now, so the advice is still the same: update configure script :) Reid. On Sun, 2004-09-05 at 09:53, Jeff Cohen wrote: > Configure gives me these errors on FreeBSD. I'm proceding with the build anyway to see what happens. Don't worry :)

LLVMers, The 2.2 prerelease is now available for testing: http://llvm.org/prereleases/2.2/ If anyone can help test this release, I ask that you do the following: 1) Build llvm and llvm-gcc (or use a binary). You may build release (default) or debug. You may pick llvm-gcc-4.0, llvm-gcc-4.2, or both. 2) Run 'make check'. 3) In llvm-test, run 'make TEST=nightly report'. 4) When

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/17/2010 10:12 PM, Tanya Lattner wrote: > The 2.7 binaries are available for testing: > http://llvm.org/pre-releases/2.7/pre-release1/ > > You will also find the source tarballs there as well. > > We rely on the community to help make our releases great, so please help > test 2.7 if you can. Please follow these instructions to test 2.7: > > /To test llvm-gcc:/

Hi Tanya, > 1) Compile llvm from source and untar the llvm-test in the projects > directory (name it llvm-test or test-suite). Choose to use a > pre-compiled llvm-gcc or re-compile it yourself. I compiled llvm and llvm-gcc with separate objects directories. Platform is x86_64-linux-gnu. > 2) Run make check, report any failures (FAIL or unexpected pass). Note > that you need to

On Mar 24, 2010, at 2:47 PM, Török Edwin wrote: > On 03/17/2010 10:12 PM, Tanya Lattner wrote: >> The 2.7 binaries are available for testing: >> http://llvm.org/pre-releases/2.7/pre-release1/ >> >> You will also find the source tarballs there as well. >> >> We rely on the community to help make our releases great, so please help >> test 2.7 if you

The 2.7 binaries are available for testing: http://llvm.org/pre-releases/2.7/pre-release1/ You will also find the source tarballs there as well. We rely on the community to help make our releases great, so please help test 2.7 if you can. Please follow these instructions to test 2.7: To test llvm-gcc: 1) Compile llvm from source and untar the llvm-test in the projects directory (name it

LLVMers, The 2.1 pre-release (version 1) is available for testing: http://llvm.org/prereleases/2.1/version1/ I'm looking for members of the LLVM community to test the 2.1 release. There are 2 ways you can help: 1) Download llvm-2.1, llvm-test-2.1, and the appropriate llvm-gcc4.0 binary. Run "make check" and the full llvm-test suite (make TEST=nightly report). 2) Download

LLVMers, 2.6 pre-release2 is ready to be tested by the community. http://llvm.org/prereleases/2.6/ If you have time, I'd appreciate anyone who can help test the release. To test llvm-gcc: 1) Compile llvm from source and untar the llvm-test in the projects directory (name it llvm-test or test-suite). Choose to use a pre- compiled llvm-gcc or re-compile it yourself. 2) Run make check,

Andy and I briefly discussed this the other day, we have not yet got chance to list a detailed pass order for the pre- and post- IPO scalar optimizations. This is wish-list in our mind: pre-IPO: based on the ordering he propose, get rid of the inlining (or just inline tiny func), get rid of all loop xforms... post-IPO: get rid of inlining, or maybe we still need it, only

G'Day Tanya, Is it too late to bring in the following patches to fix some major brokenness in the AuroraUX tool chain for 2.6? http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?r1=84468&r2=84469&view=diff&pathrev=84469 http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?r1=84265&r2=84266&view=diff&pathrev=84266

LLVMers, The 2.5 pre-release is available for testing: http://llvm.org/prereleases/2.5/ If you have time, I'd appreciate anyone who can help test the release. Please do the following: 1) Download/compile llvm source, and either compile llvm-gcc source or use llvm-gcc binary (please compile llvm-gcc with fortran if you can). 2) Run make check, send me the testrun.log 3) Run "make

Are these 225 compile time regressions real? It sure looks bad! Ciao, Duncan. On 01/12/11 09:39, llvm-testresults at cs.uiuc.edu wrote: > > bwilson__llvm-gcc_PROD__i386 nightly tester results > > URL http://llvm.org/perf/db_default/simple/nts/380/ > Nickname bwilson__llvm-gcc_PROD__i386:4 > Name curlew.apple.com > > Run ID Order Start Time End Time > Current 380

I have built and configured the test suits as told at http://llvm.org/docs/TestingGuide.html#testsuite. The llvm is built with configuration: SRC_DIR/configure --prefix=INS_DIR --enable-debug-runtime --disable-optimized --enable-debug-symbols --enable-assertions This configuration is used again in the re-configure process. However, after the re-configure process, the following "make"

On 10/25/2017 12:32 PM, Evgeny Astigeevich wrote: > > Hi Hal, > > I quickly checked the execution profile. It is real. The code changed > significantly. A number of the hottest regions changed. I’ll compare IRs. > Thanks. Obviously a 1000% execution performance regression seems problematic. -Hal > JFYI FreeBench/fourinarow time graph: >

On 10/25/2017 12:10 PM, Evgeny Astigeevich via llvm-dev wrote: > > Hi Chandler, > > I ran the LNT benchmarks and SPEC2k6.train on AArch64 Cortex-A57. I > used revisions: Clang 316561, LLVM 316563. > > Options: -O3 -mcpu=cortex-a57 -fomit-frame-pointer > -fexperimental-new-pass-manager > > Regressions: execution time increase > > LNT > >

Hello everyone, One of Google's summer interns, George Burgess IV, created an implementation of the CFL pointer-aliasing analysis algorithm, and this has now been added to LLVM trunk. Now we should determine whether it is worthwhile adding this to the default optimization pipeline. For ease of testing, I've added the command line option -use-cfl-aa which will cause the CFL analysis to be

> On Feb 16, 2017, at 4:41 PM, Xinliang David Li via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Thu, Feb 16, 2017 at 3:45 PM, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > First off, I just want to say wow and thank you. This kind of data is amazing. =D > > On Thu, Feb 16, 2017 at

On Mar 13, 2011, at 2:01 PM, Arnaud Allard de Grandmaison wrote: > Hi all, > > The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64, which supports natively all types, but it is a real one