search for: preopts

Displaying 20 results from an estimated 44 matches for "preopts".

Did you mean: prepopts
2018 May 15
1
Four bitcode generated with plugin-opt=save-temps
Hi Teresa Thanks for your very quick and clear explanation. I have one more question. The emit-llvm option will give you the IR for a single source file when you compile it with -c. All of those files when combined give the IR in the preopt.bc temp file. =========== So if I use "clang -emit-llvm -c" to generate the .ll file. It should be the same as the one I generated by using
2018 May 15
2
Four bitcode generated with plugin-opt=save-temps
Hi I use the LDFLAGS=" -flto -fuse-ld=gold -Wl,-plugin-opt=save-temps " to generate the makefile and to make the whole program. However, found four different kinds of bitcode for each target. For example, I am compiling coreutils. For the program "nohup", I can get nohup.0.0.preopt.bc nohup.0.2.internalize.bc nohup.0.4.opt.bc nohup.0.5.precodegen.bc If I am right, I
2018 May 15
0
Four bitcode generated with plugin-opt=save-temps
These are the bitcode at different stages of the LTO portion of the compile. LTO merges the IR for all files being linked and optimizes them as a single monolithic module. The preopt.bc is the merged IR just after merging and before performing any LTO optimizations. internalize.bc is after performing whole program internalization. opt.bc is after the optimization pipeline, and .precodegen.bc is
2016 Nov 10
2
Polly | Dependence detection details
Hi everyone, I'll be very thankful if anyone can help me. I want to extract the dependences details by using polly. I followed the following steps on example code matmul.c: 1. clang -S -emit-llvm matmul.c -o matmul.s 2. opt -S -polly-canonicalize matmul.s > matmul.preopt.ll 3. opt -basicaa -polly-dependences -analyze matmul.preopt.ll But it doesn't show me the dependences. I
2013 Aug 16
2
[LLVMdev] [Polly] Analysis of extra compile-time overhead for simple nested loops
At 2013-08-16 12:44:02,"Tobias Grosser" <tobias at grosser.es> wrote: >Hi, > >I tried to reproduce your findings, but could not do so. Sorry, I did not put all code in my previous email because the code seems a little too long and complicated. You can refer to the detailed C code and LLVM IR code on http://llvm.org/bugs/show_bug.cgi?id=16843 There are four attachments
2013 Aug 16
0
[LLVMdev] [Polly] Analysis of extra compile-time overhead for simple nested loops
On 08/16/2013 02:42 AM, Star Tan wrote: > At 2013-08-16 12:44:02,"Tobias Grosser" <tobias at grosser.es> wrote: >> Hi, >> >> I tried to reproduce your findings, but could not do so. > > > Sorry, I did not put all code in my previous email because the code seems a little too long and complicated. > You can refer to the detailed C code and LLVM IR
2011 Nov 01
0
[LLVMdev] How to make Polly ignore some non-affine memory accesses
Mmm, this code seems to kill polly: #include <stdio.h> #include <stdlib.h> int main() { char *B; int i,j,k,h; const int x = 0, y=0; B = (char *)malloc(sizeof(char)*1024*1024); for (i = 1; i < 1024; i++) for (j = 1; j < 1024; j++) { if (i+j > 1000) B[j] = i; } printf("Random Value: %d", B[rand() % 1024*1024]); return 0; } running: opt
2011 Oct 27
2
[LLVMdev] How to make Polly ignore some non-affine memory accesses
Perfect, thank you very much :) 2011/10/26 Tobias Grosser <tobias at grosser.es>: > On 10/24/2011 11:32 PM, Marcello Maggioni wrote: >> >> Strange , with --enable-shared (I use auto tool by the way ...) it gives: >> >> MacBook-Pro-di-Marcello:examples Kariddi$ ./compile_ex.sh >> not_so_simple_loop >> clang (LLVM option parsing): Unknown command line
2011 Oct 07
1
[LLVMdev] How to make Polly ignore some non-affine memory accesses
I add also the output of these commands: [hades at artemis examples]$ ./compile_ex.sh super_simple_loop Printing analysis 'Polly - Detect Scops in functions' for function 'main': [hades at artemis examples]$ modifying it in : #include <stdio.h> int main() { int A[1024]; int j, k=10; for (j = 0; j < 1024; j++) A[j] = k;
2013 Aug 16
0
[LLVMdev] [Polly] Analysis of extra compile-time overhead for simple nested loops
On 08/15/2013 03:32 AM, Star Tan wrote: > Hi all, Hi, I tried to reproduce your findings, but could not do so. > I have investigated the 6X extra compile-time overhead when Polly compiles the simple nestedloop benchmark in LLVM-testsuite. (http://188.40.87.11:8000/db_default/v4/nts/31?compare_to=28&baseline=28). Preliminary results show that such compile-time overhead is resulted by
2018 Jun 03
2
Function start address
Hi Muhui, I tried to grep the "DW_TAG_subprogram" from the debug_info . However, I noticed that the number I found is still less than the whole functions I found with LLVM IR. Do you have any experiences? Many Thanks The only explanation that comes to mind, is that the functions are not in the final binary object file. However, previously you said you believed they were present. If
2011 Oct 08
0
[LLVMdev] How to make Polly ignore some non-affine memory accesses
On 10/07/2011 03:43 PM, Marcello Maggioni wrote: > 2011/10/7 Marcello Maggioni<hayarms at gmail.com>: >> Hi, >> >> for example this loop: >> >> #include<stdio.h> >> >> int main() >> { >> int A[1024]; >> int j, k=10; >> for (j = 1; j< 1024; j++) >> A[j] =
2013 Aug 17
2
[LLVMdev] [Polly] Analysis of extra compile-time overhead for simple nested loops
At 2013-08-16 22:32:30,"Tobias Grosser" <tobias at grosser.es> wrote: >> >> Yes, I have changed the original code to the form you suggested: >> for (i >> for (j >> ... >> x=1 > >Sorry, I meant > x[0] += > It is interesting that Polly would run much faster if we change the
2018 Jan 29
1
Polly loop offloading to Accelerator
Thank You. i used -polly-ast-detect-parallel but there is no coincident info generated; my c code is simple vec-sum as follows; #include <stdio.h> int a[2048], b[2048], c[2048]; foo () { int i; for (i=0; i<2048; i++) { a[i]=b[5] + c[i]; } } i executed following commands; $clang -S -emit-llvm vec-sum.cpp -march=native -O3 -mllvm -disable-llvm-optzns -o vec-sum.s $opt -S
2013 Sep 30
0
[LLVMdev] [Polly] Move Polly's execution later
At 2013-09-25 18:03:18,"Tobias Grosser" <tobias at grosser.es> wrote:> >I think this is too early, as most of the canonicalization is not yet  >done. We probably don't need to investigate this bug immediately, but >it would be nice if we could make it reproducible without your changes  >to polly. For this please run the command with -debug-pass=Arguments
2018 Jan 29
2
Polly Dependency Analysis in MyPass
i put following line in CMakeLists.txt; add_subdirectory(mypass) then used make -j9 then i used following and run on canonicalize IR $ opt -load lib/LLVMmypass.so -mypass vec-sum.preopt.ll On Mon, Jan 29, 2018 at 9:39 PM, Michael Kruse <llvmdev at meinersbur.de> wrote: > 2018-01-29 10:18 GMT-06:00 hameeza ahmed <hahmed2305 at gmail.com>: > > I tried writing
2019 Jan 18
2
Is it possible to generate the IR representation with the original macro information?
Hi, I use the following commands to compile the IR. But I don't see the macro information in the .ll file. Is there a way to preserve the macro information (print() in this case) for debugging purposes? $ clang -std=gnu99 -g3 -flto -Wall -pedantic -c -o main.o main.c $ clang main.o -flto -fuse-ld=gold '-Wl,-plugin-opt=save-temps' -o main.exe $ llvm-dis main.exe.0.0.preopt.bc /* vim:
2011 Oct 03
4
[LLVMdev] How to make Polly ignore some non-affine memory accesses
Hi Tobias, thanks for the answer. I'll try to give a look to the code you pointed me to , and I'll try to make the modification myself. I'm new to LLVM and Polly, but the code of both seem clean and understandable, so I hope to be able to do it myself. In case I'll ask here for support :) Marcello 2011/10/1 Tobias Grosser <tobias at grosser.es>: > On 10/01/2011 03:26
2013 Aug 15
4
[LLVMdev] [Polly] Analysis of extra compile-time overhead for simple nested loops
Hi all, I have investigated the 6X extra compile-time overhead when Polly compiles the simple nestedloop benchmark in LLVM-testsuite. (http://188.40.87.11:8000/db_default/v4/nts/31?compare_to=28&baseline=28). Preliminary results show that such compile-time overhead is resulted by the complicated polly-dependence analysis. However, the key seems to be the polly-prepare pass, which introduces
2013 Oct 03
1
[LLVMdev] [Polly] Move Polly's execution later
On 09/30/2013 04:11 AM, Star Tan wrote: > At 2013-09-25 18:03:18,"Tobias Grosser" <tobias at grosser.es> wrote:> >> I think this is too early, as most of the canonicalization is not yet >> done. We probably don't need to investigate this bug immediately, but >> it would be nice if we could make it reproducible without your changes >> to polly. For