similar to: [LLVMdev] Performance Tracking

On Nov 14, 2011, at 10:46 AM, David Chisnall wrote: > Hello Everyone, > > I've been looking at benchmarks of LLVM recently, and overall they look pretty good. Aside from things that use OpenMP or benefit from autovectorisation, Clang/LLVM and GCC seem to come fairly close, with no overall winner. Nice. Thanks. > > But: there do seem to have been a number of performance

Le 14 novembre 2011 20:40, Evan Cheng <evan.cheng at apple.com> a écrit : > > On Nov 14, 2011, at 10:46 AM, David Chisnall wrote: > > > Hello Everyone, > > > > I've been looking at benchmarks of LLVM recently, and overall they look > pretty good. Aside from things that use OpenMP or benefit from > autovectorisation, Clang/LLVM and GCC seem to come

Hi, I'm proposing to make vectorizer-maximize-bandwidth on by default for loop vectorizer because it should generally help performance. I've tested the performance impact on Intel sandybridge machine with speccpu benchmarks: Benchmark Base:Reference (1) ------------------------------------------------------- spec/2006/fp/C++/444.namd 26.84

After update the system now I use: Kernel 3.9.2 x server 1.12.4 nouveau 1.0.7 the xorg config are at: http://pastebin.com/2LUxLiVs It's the one installed by my distro, without any modification I have made 2 test. Normal boot Xorg at http://pastebin.com/reZdAXEF GLX Renderer is detected as GLX "Mesa DRI nv18 x86/MMX+/3DNow!+/SSE GLX" Same configuration with nomodeset Xorg log

Hi everyone, The code layout that TailMerging (inside BranchFolding) works on is not the final layout optimized based on the branch probability. Generally, after BlockPlacement, many new merging opportunities emerge. I did an experiment of adding additional BranchFolding and BlockPlacement after the existing BlockPlacement (i.e., -block-placement -branch-folder -block-placement) targeting

Hi! I have some strange results on my test with nouveau drivers I'm using a old GeForce4 MX 4000 (NV18) with 128 MB. I have made 2 test. -The default configuration, using nomodeset without nouveau_vieux_dri.so $inxi -G Graphics: Card: NVIDIA NV18 [GeForce4 MX 4000] X.Org: 1.12.4 drivers: vesa,nouveau (unloaded: fbdev) Resolution: 1024x768 at 0.0hz GLX Renderer: N/A

Hi, We are currently working on revising a journal article that describes our work on pre-allocation scheduling using LLVM and have some questions about LLVM's pre-allocation scheduler. The answers to these question will help us better document and analyze the results of our benchmark tests that compare our algorithm with LLVM's pre-allocation scheduling algorithm. First, here is a

The impact to debug_line is actually not small. I only implemented the part 1 (encoding duplication factor) for loop unrolling and loop vectorization. The debug_line size overhead for "-O2 -g1" binary of speccpu C/C++ benchmarks: 433.milc 23.59% 444.namd 6.25% 447.dealII 8.43% 450.soplex 2.41% 453.povray 5.40% 470.lbm 0.00% 482.sphinx3 7.10% 400.perlbench 2.77% 401.bzip2 9.62% 403.gcc

Hi Nadav, Unfortunately I'm not attending the dev meeting, but the BoF looks interesting. One thing that I'd like to throw into the mix is that, while dealing with autovectorisation of LLVM compiled down from C-like languages (or maybe Fortran-like languages) is clearly a very big area for fruitful work both algorithmically and in terms of practical relevance, it'd also be interesting

Hi David! On Nov 6, 2012, at 3:23 AM, David Tweed <david.tweed at gmail.com> wrote: > Hi Nadav, > > Unfortunately I'm not attending the dev meeting, but the BoF looks interesting. One thing that I'd like to throw into the mix is that, while dealing with autovectorisation of LLVM compiled down from C-like languages (or maybe Fortran-like languages) is clearly a very big

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 > >

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: >

The large percentages are from those tiny benchmarks. If you look at omnetpp (0.52%), and xalanc (1.46%), the increase is small. To get a better average increase, you can sum up total debug_line size before and after and compute percentage accordingly. David On Thu, Oct 27, 2016 at 1:11 PM, Dehao Chen <dehao at google.com> wrote: > The impact to debug_line is actually not small. I only

----- Original Message ----- > From: "Nadav Rotem" <nrotem at apple.com> > To: "David Tweed" <david.tweed at gmail.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Tuesday, November 6, 2012 11:08:23 AM > Subject: Re: [LLVMdev] Regarding BOF: Vectorization in LLVM > > Hi David! > > On Nov 6, 2012, at 3:23 AM, David Tweed <david.tweed at

Hi I am using SanitizerCoverage feature supported by clang to get the basicblock coverage. my tested binaries are spec cpu2006. I compiled the binary with the option COPTIMIZE = -O0 -fsanitize=address -fsanitize-coverage=bb -flto -fno-strict-aliasing -std=gnu89 -gdwarf-3 After the compiling process is end. I run the 400.perlbench. with the command ASAN_OPTIONS=coverage=1 ./perlbench.

Hello, I am new in using llvm so I would like to get some help on how to compile test-suite. Assumptions: llvm is in /llvm directory llvm-gcc is in /llvm-4.2-2.4-x86-linux-RHEL4/bin I have tried compiling test-suite and I get the following error: $make make[1]: Entering directory '/llvm/projects/test-suite/SingleSource' make[2]: Entering directory

Hi If so, is it able to disable this check. All I need is just to get the BB coverage information Regards Muhui Alexander Potapenko <glider at google.com>于2018年9月5日 周三下午6:57写道： > This is a known problem in SPECCPU2006, see > https://github.com/google/sanitizers/wiki/AddressSanitizerFoundBugs > On Wed, Sep 5, 2018 at 7:36 AM Muhui Jiang via llvm-dev > <llvm-dev at

On Sep 29, 2012, at 2:43 AM, Ghassan Shobaki <ghassan_shobaki at yahoo.com> wrote: > Hi, > > We are currently working on revising a journal article that describes our work on pre-allocation scheduling using LLVM and have some questions about LLVM's pre-allocation scheduler. The answers to these question will help us better document and analyze the results of our benchmark

Hi Alex Thanks for your email. But it seems not work. I removed the -fsanitize=address flag. The global buffer overflow message doesn't show. However, no *.sancov file is created after I run perlbench. Thus, I could not get the BB coverage. Do you have any ideas? Many Thanks Regards Muhui Alexander Potapenko <glider at google.com> 于2018年9月5日周三 下午7:14写道： > Hi Muhui, > > If

----- Original Message ----- > From: "Tobias Edler von Koch" <tobias at codeaurora.org> > To: "Daniel Berlin" <dberlin at dberlin.org> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, June 11, 2015 10:02:37 AM > Subject: Re: [LLVMdev] BasicAA unable to analyze recursive PHI nodes > > Hi Daniel,