similar to: [LLVMdev] Protecting a register value in the LLVM backend

Marcello Maggioni <hayarms at gmail.com> writes: > I'm working on an LLVM backend for a new target architecture which has > some instructions that when executed implicitly produce a result in a > particular register after a certain amount of cycles. > > The situation is this : > > 1: Execute instruction > 2: Wait for result > 3: Wait for result > 4: Wait

Hi David, can you point me to an instruction in the X86 architecture that uses this? The MUL instruction would be a good example? Thanks Marcello 2012/10/2 <dag at cray.com> > Marcello Maggioni <hayarms at gmail.com> writes: > > > I'm working on an LLVM backend for a new target architecture which has > > some instructions that when executed implicitly produce

Something like, keeping the compiler alive for a many compilation sessions, using the same LLVMContext, but without the problem of accumulating data in the LLVMContext that would slowly fill up the memory. This as much I can enter into details that I can :/ Probably this is also a quite common use case scenario too. Marcello 2014-06-24 18:52 GMT+01:00 Eric Christopher <echristo at

This is the .ll for that graph (attached). I think I understand what you are saying. This particular testcase returns CNC not because the exit block doesn't have a unique predecessor, but because the unique predecessor (the inner loop block) has a successor that is inside the loop (in this case itself, because it's the inner loop block). That doesn't change, anyway, the assuption that

FInally I had the time to complete everything up. Now I included the test case in the patch and the testcase runs with the LLVM tests system. 2012/2/9 Marcello Maggioni <hayarms at gmail.com>: > This is instead a very simple (handmade) test case that triggers the > problem (attached) > Also a more conforming patch has been attached > > 2012/2/9 Marcello Maggioni <hayarms

Hello, the need here is to have a single LLVMContext used for multiple compilations. You make a good point about that by the way. If there are outstanding users cleaning the context under their seats might still pose a risk to them, and in that case deleting + newing a new LLVMContextImpl might actually not be very different. Marcello 2014-06-24 17:14 GMT+01:00 David Blaikie <dblaikie at

On 11/18/2011 01:36 PM, Marcello Maggioni wrote: > 2011/11/18 Marcello Maggioni<hayarms at gmail.com>: >> The patch is attached. >> >> The patch to correct the test runs on OSX will be posted shortly after >> this one (I preferred to separate the two so that a problem with >> either one of the two wouldn't give problems to the other and also to >>

Well, it wasn't intended as a "real" patch to be included , but more as a "proof of concept" for a solution. Do you think it is a valid solution and I'm correct in my assumption? If so then I'll clean up the patch and attach a testcase for inclusion. Thanks! Marcello 2012/2/9 Nick Lewycky <nlewycky at google.com>: > Your patch should include a testcase,

This is instead a very simple (handmade) test case that triggers the problem (attached) Also a more conforming patch has been attached 2012/2/9 Marcello Maggioni <hayarms at gmail.com>: > This is the .ll for that graph (attached). I think I understand what > you are saying. > This particular testcase returns CNC not because the exit block > doesn't have a unique predecessor,

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

Attached 2012/2/8 Marcello Maggioni <hayarms at gmail.com>: > Mmm, sorry, the patch I posted crashes if ExitBr is null (which it may > be ...) , this one should be ok (and passess all the ScalarEvolution > tests in LLVM): > > diff --git a/lib/Analysis/ScalarEvolution.cpp b/lib/Analysis/ScalarEvolution.cpp > index daf7742..b10fab2 100644 > ---

On 8 February 2012 15:50, Marcello Maggioni <hayarms at gmail.com> wrote: > Well, it wasn't intended as a "real" patch to be included , but more > as a "proof of concept" for a solution. Do you think it is a valid > solution and I'm correct in my assumption? If so then I'll clean up > the patch and attach a testcase for inclusion. > I'm

2011/11/18 Marcello Maggioni <hayarms at gmail.com>: > 2011/11/15 Marcello Maggioni <hayarms at gmail.com>: >> 2011/11/14 Tobias Grosser <tobias at grosser.es>: >>> On 11/14/2011 02:45 PM, Marcello Maggioni wrote: >>>> >>>> 2011/11/14 Tobias Grosser<tobias at grosser.es>: >>>>> >>>>> On 11/14/2011 01:24

2011/11/15 Marcello Maggioni <hayarms at gmail.com>: > 2011/11/14 Tobias Grosser <tobias at grosser.es>: >> On 11/14/2011 02:45 PM, Marcello Maggioni wrote: >>> >>> 2011/11/14 Tobias Grosser<tobias at grosser.es>: >>>> >>>> On 11/14/2011 01:24 AM, Marcello Maggioni wrote: >>>>> >>>>> Hi Tobias.

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

Your patch should include a testcase, see test/Analysis/ScalarEvolution for examples. "BranchInst* " should be "BranchInst *". You should have spaces after the // in your comments. One of the comment lines isn't indented properly. Nick On 8 February 2012 12:05, Marcello Maggioni <hayarms at gmail.com> wrote: > Attached > > 2012/2/8 Marcello Maggioni

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

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;

Hello, I'm finding problems with BackEdgeTaken count calculation in even simple fortran loops with gfortran-4.6 + DragonEgg 3.0. Even for simple double loops like this one: program test2 integer i,j,k dimension k(100,100) do j=1,100 do i=1,100 k(i,j) = i enddo enddo write(*,*) k(1,30) end make the ScalarEvolution

I was trying the new feature you introduce about printing out the graphs, so I updated my version of llvm/clang/polly synchronizing them to the last version, but I get this error launching clang (also , I recently switched to MacOS X for development): $ clang not_so_simple_loop.c -O3 -Xclang -load -Xclang ${PATH_TO_POLLY_LIB}/LLVMPolly.dylib -mllvm -enable-polly-viewer -mllvm -enable-iv-rewrite