similar to: [LLVMdev] [Polly] Set up performance tester for GSOC2013 FastPolly project

On 06/06/2013 11:17 AM, Star Tan wrote: > Hi Tobias, > > > I am recently trying to set up the performance tester for FastPolly project. According to your suggestion, I plan to use the LNT infrastructure to set up the performance tester. For this purpose, I think I should do this job in three steps: > > > First, I will add PolyBench to LLVM test-suite since PolyBench is the

Hi all, I have investigated the compile-time overhead of "Polly Scop Detection" pass based on LNT testing results. This mail is to share some results I have found. (1) Analysis of "SCOP Detection Pass" for PolyBench (Attached file PolyBench_SCoPs.log) Experimental results show that the "SCOP Detection pass" does not lead to significant extra compile-time

At 2013-06-30 08:34:34,"Tobias Grosser" <tobias at grosser.es> wrote: >On 06/29/2013 05:04 PM, Star Tan wrote: >> Hi all, >> >> >> >> I have investigated the compile-time overhead of "Polly Scop Detection" pass based on LNT testing results. >> This mail is to share some results I have found. >> >> >> (1) Analysis

On 06/29/2013 05:04 PM, Star Tan wrote: > Hi all, > > > > I have investigated the compile-time overhead of "Polly Scop Detection" pass based on LNT testing results. > This mail is to share some results I have found. > > > (1) Analysis of "SCOP Detection Pass" for PolyBench (Attached file PolyBench_SCoPs.log) > Experimental results show that the

At 2013-08-12 01:18:30,"Tobias Grosser" <tobias at grosser.es> wrote: >On 08/10/2013 06:59 PM, Star Tan wrote: >> Hi all, >> >> I have evaluated Polly's performance on LLVM test-suite with latest LLVM (r188054) and Polly (r187981).  Results can be viewed on: http://188.40.87.11:8000. > >Hi Star Tan, > >thanks for the update. >

On 08/10/2013 06:59 PM, Star Tan wrote: > Hi all, > > I have evaluated Polly's performance on LLVM test-suite with latest LLVM (r188054) and Polly (r187981). Results can be viewed on: http://188.40.87.11:8000. Hi Star Tan, thanks for the update. > There are mainly five new tests and each test is run with 10 samples: > clang (run id = 27): clang -O3 > pollyBasic (run id =

Hi all, I have evaluated Polly's performance on LLVM test-suite with latest LLVM (r188054) and Polly (r187981).  Results can be viewed on: http://188.40.87.11:8000. There are mainly five new tests and each test is run with 10 samples: clang (run id = 27):  clang -O3 pollyBasic (run id = 28):  clang -O3 -load LLVMPolly.so pollyNoGen (run id = 29):  pollycc -O3 -mllvm -polly-optimizer=none

>> (3) About detecting scop regions in bottom-up order. >> Detecting scop regions in bottom-up order can significantly speed up the scop detection pass. However, as I have discussed with Sebastian, detecting scops in bottom-up order and up-bottom order will lead to different results. As a result, we should not change the detection order. > >Sebastian had a patch for this. Does

On 07/01/2013 06:51 AM, Star Tan wrote: >> Great. Now we have two test cases we can work with. Can you > >> upload the LLVM-IR produced by clang -O0 (without Polly)? > Since tramp3d-v4.ll is to large (19M with 267 thousand lines), I would focus on the oggenc benchmark at firat. > I attached the oggenc.ll (LLVM-IR produced by clang -O0 without Polly), which compressed into the

>Great. Now we have two test cases we can work with. Can you >upload the LLVM-IR produced by clang -O0 (without Polly)? Since tramp3d-v4.ll is to large (19M with 267 thousand lines), I would focus on the oggenc benchmark at firat. I attached the oggenc.ll (LLVM-IR produced by clang -O0 without Polly), which compressed into the file oggenc.tgz. >2) Check why the Polly scop detection is

On 04/26/2013 05:08 AM, tanmx_star wrote: > Hi all, Hi, thanks for the update and sorry for the delay in reviewing. I just had a look at your proposal. > I have updated my GSoS proposal: "FastPolly: Reducing LLVM-Polly Compiling overhead" (https://gist.github.com/tanstar/5441808). I think the pass ordering problem you discussed early can be also investigated in this project!

Hi all, I have updated my GSoS proposal: "FastPolly: Reducing LLVM-Polly Compiling overhead" (https://gist.github.com/tanstar/5441808). I think the pass ordering problem you discussed early can be also investigated in this project! Is there any comment or advice about my proposal? I appreciate all your help and advice. Thanks, Star Tan Proposal:

On Wed, Oct 12, 2016 at 10:53 AM, Hal Finkel <hfinkel at anl.gov> wrote: > I don't think that Clang/LLVM uses it by default on x86_64. If you're using -Ofast, however, that would explain it. I recommend looking at -O3 vs -O0 and make sure those are the same. -Ofast enables -ffast-math, which can legitimately cause differences. > The following tests pass at "-O3" and

On Fri, Oct 14, 2016 at 6:10 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> polybench/linear-algebra/kernels/symm, FP_ABSTOLERANCE=1e1 >> polybench/linear-algebra/solvers/gramschmidt, FP_ABSTOLERANCE=1e0 >> What should be a good relative tolerance to set for these two tests? > > What's the minimum relative tolerance that you need for them to pass? Setting

Hi all, PolyBench (http://www.cse.ohio-state.edu/~pouchet/software/polybench/) is a well-known benchmark for polyhedral compiler. Since LLVM-Polly http://polly.llvm.org/) has provided a very good polyhedral optimizer for LLVM, could we add this benchmark to LLVM test-suite? I have attached the patch file to add PolyBench to LLVM test-suite. Best wishes, Star Tan -------------- next part

On Fri, Oct 14, 2016 at 10:50 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Renato Golin" <renato.golin at linaro.org> >> To: "Sebastian Pop" <sebpop.llvm at gmail.com> >> Cc: "Hal Finkel" <hfinkel at anl.gov>, "Sebastian Paul Pop" <s.pop at samsung.com>,

Hey folks, Some progress has been made since the first thread: http://lists.llvm.org/pipermail/llvm-dev/2017-March/111129.html And also I think the consensus is to enable "-ffp-contract=on" by default (instead of "fast"), which seems to be working on some preliminary tests I made. I just ran the test-suite on x86_64 and AArch64. The former is ok, the latter still has some

On 05/03/2013 11:39 AM, Star Tan wrote: > Dear Tobias, > > > Thank you very much for your very helpful advice. > > > Yes, -debug-pass and -time-passes are two very useful and powerful > options when evaluating the compile-time of each compiler pass. They > are exactly what I need! With these options, I can step into details > of the compile-time overhead of each pass.

Hi all, We are trying to add Polybench[1] to the LLVM test suite. So far we have all but five benchmarks working fine. The problems we're having in those five benchmarks are due to gcc's versus clang's different ways to output 'Nan's. We are working to solve this. Although the patch is not ready yet to be included in the LLVM test suite, we would like to have some feedback

> On Oct 7, 2016, at 5:56 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ----- Original Message ----- >> From: "Sebastian Pop" <sebpop.llvm at gmail.com <mailto:sebpop.llvm at gmail.com>> >> To: "Renato Golin" <renato.golin at linaro.org <mailto:renato.golin at linaro.org>> >> Cc: "Kristof