similar to: [LLVMdev] [Patch] Apply for adding PolyBench to LLVM testsuite

On 06/08/2013 11:26 PM, Star Tan wrote: > 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

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

Bill, > Hi Pawel, > > Could you branch polly as well for the 3.2 release? We will need to contact the 'polly' guys to figure out how best to add it to the release (testing, etc.). Sure. But I do not know much about polly so 'polly' guys please fill me on the details. For the 3.2 release I will need: - to know how to build it seems to be covered here

On Nov 13, 2012, at 11:16 AM, Pawel Wodnicki <pawel at 32bitmicro.com> wrote: > Bill, > >> Hi Pawel, >> >> Could you branch polly as well for the 3.2 release? We will need to contact the 'polly' guys to figure out how best to add it to the release (testing, etc.). > > Sure. > > But I do not know much about polly so 'polly' guys please

It would help if you sent the IR you're giving to opt or at least a complete C function and your clang command line. ~Craig On Wed, Mar 14, 2018 at 3:05 PM, hameeza ahmed <hahmed2305 at gmail.com> wrote: > Hello, > > I m unable to vectorize following kernel by opt tool; > > for (i = 0; i < _PB_NI; i++) > for (j = 0; j < _PB_NJ; j++) > { >

Hello, I m unable to vectorize following kernel by opt tool; for (i = 0; i < _PB_NI; i++) for (j = 0; j < _PB_NJ; j++) { tmp[i][j] = 0; for (k = 0; k < _PB_NK; ++k) tmp[i][j] += alpha * A[i][k] * B[k][j]; } for (i = 0; i < _PB_NI; i++) for (j = 0; j < _PB_NL; j++) { D[i][j] *= beta; for (k = 0; k < _PB_NJ; ++k) D[i][j] +=

hi Tobi , that sounds greate :D On 2009-12-27 5:43, Tobias Grosser wrote: > I already looked into implementing something like Graphite for LLVM. > However just recently, so I have not released any code yet. As soon as > some code is available I will post patches. whats its status? do you need any help? > A general plan to implement polyhedral transformations in LLVM: > > 1.

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 Tue, Oct 11, 2016 at 10:39 PM, Sebastian Pop <sebpop.llvm at gmail.com> wrote: > On Tue, Oct 11, 2016 at 10:20 PM, 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

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 Kun Ling & Bergstrom, Thanks a lot for your earlier responses. We did use the benchmarks in llvm testsuite for comparing execution time taken by clang & gcc. It appears that clang is slower than gcc for cases where floating point operations are involved and recursive calls are involved (note that pic/pie was enabled for both gcc as well as clang ). 1) For lag in execution time due to

Hi ether, On 12/26/09 13:06, ether zhhb wrote: > hi, > > dose anyone going/planning to add something like > Graphite(http://gcc.gnu.org/wiki/Graphite) in gcc to llvm(or that > should be implement at the level of clang?)? I already looked into implementing something like Graphite for LLVM. However just recently, so I have not released any code yet. As soon as some code is

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

Hi All, Could anyone point me to some good benchmarking tools to measure the runtime performance of clang compiled C++ applications. Thanks ! - Jyoti -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131003/3cc029f1/attachment.html>

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, I'm trying to get the llvm's IR from the source code of Polybench (OMP) https://github.com/cavazos-lab/PolyBench-ACC/tree/master/OpenMP. I noticed a considerable difference between the IR generated using clang -emit-llvm -fopenmp and clang -emit-llvm: * using the -fopenmp flag I get a simplified IR in which I read a single basic block where I can highlight a llvm.memcpy

ether wrote: >> The polyhedral loop description is simple and not compiler depended. >> Therefore external tools like LooPo (automatic parallelization), Pluto >> (optimization in general) > i had contacted the author a week ago, and if we use it, we need a IR > generator in llvm side to extract SCoP, and the corresponding parser in > Pluto side that read, then a

Hi, I would need some help to fix polybench/symm: void kernel_symm(int ni, int nj, DATA_TYPE alpha, DATA_TYPE beta, DATA_TYPE POLYBENCH_2D(C,NI,NJ,ni,nj), DATA_TYPE POLYBENCH_2D(A,NJ,NJ,nj,nj), DATA_TYPE POLYBENCH_2D(B,NI,NJ,ni,nj)) { int i, j, k; DATA_TYPE acc; /* C := alpha*A*B + beta*C, A is symetric */ for (i = 0; i < _PB_NI; i++) for (j = 0; j < _PB_NJ; j++) {

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!