Hi Renato, No, I cannot, but in case it is, I want to take advantage of this. In case it is not, the instrumentation code will detect this at runtime and simply roll back to the original version. I will always keep an original version available, in addition to the ones I modify with Polly. However, initially I will speculate that it is allocated contiguously. Thanks, Alexandra ________________________________ From: Renato Golin <rengolin at systemcall.org> To: Jimborean Alexandra <xinfinity_a at yahoo.com> Cc: Tobias Grosser <tobias at grosser.es>; llvmdev at cs.uiuc.edu Sent: Tue, July 19, 2011 11:39:02 AM Subject: Re: [LLVMdev] speculative parallelization in LLVM On 19 July 2011 10:12, Jimborean Alexandra <xinfinity_a at yahoo.com> wrote:> %curr_array = alloca [10 x %struct.linked], align 8 > > while.. > %tmp16 = getelementptr inbounds [10 x %struct.linked]* %curr_array, i32 0, > i32 1Hi Alexandra, Can you guarantee that the linked list will be allocated in contiguous memory? cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110719/000446d3/attachment.html>
On 07/19/2011 11:46 AM, Jimborean Alexandra wrote:> Hi Renato, > > No, I cannot, but in case it is, I want to take advantage of this. In > case it is not, the instrumentation code will detect this at runtime and > simply roll back to the original version. I will always keep an original > version available, in addition to the ones I modify with Polly. However, > initially I will speculate that it is allocated contiguously.Keeping the original version should be easy, as Polly always leaves both versions in the LLVM-IR. At the moment we have if (true) new_version else old_version You could just replace the true with your runtime check. Cheers Tobi
I might need a switching mechanism a little bit more complicated to handle instrumentation, several parallel versions and the original version. And also, the "original" version I send to Polly, is not the original one generated from the source code, but the one with pointers replaced with arrays. But I will investigate the solution you propose, maybe I can adapt it and use it more easily, as it is already integrated in Polly. Alexandra ________________________________ From: Tobias Grosser <tobias at grosser.es> To: Jimborean Alexandra <xinfinity_a at yahoo.com> Cc: Renato Golin <rengolin at systemcall.org>; llvmdev at cs.uiuc.edu Sent: Tue, July 19, 2011 11:48:12 AM Subject: Re: [LLVMdev] speculative parallelization in LLVM On 07/19/2011 11:46 AM, Jimborean Alexandra wrote:> Hi Renato, > > No, I cannot, but in case it is, I want to take advantage of this. In > case it is not, the instrumentation code will detect this at runtime and > simply roll back to the original version. I will always keep an original > version available, in addition to the ones I modify with Polly. However, > initially I will speculate that it is allocated contiguously.Keeping the original version should be easy, as Polly always leaves both versions in the LLVM-IR. At the moment we have if (true) new_version else old_version You could just replace the true with your runtime check. Cheers Tobi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110719/9026ec06/attachment.html>
On 19 July 2011 10:46, Jimborean Alexandra <xinfinity_a at yahoo.com> wrote:> No, I cannot, but in case it is, I want to take advantage of this. In case > it is not, the instrumentation code will detect this at runtime and simply > roll back to the original version. I will always keep an original version > available, in addition to the ones I modify with Polly. However, initially I > will speculate that it is allocated contiguously.Sorry, I got it wrong, let me rephrase my question... How are you going to find out in compile time that the objects are in contiguous memory? In a pointer access such as: int foo(int* a, int* b) { ... } if a and b point to an list (or if the code in foo() assume they do), at least you know that the elements of a and b are in contiguous memory. But in the case of: int foo(llist a, llist b) { ... } since the next element is in the elm->next pointer, it could be pointing anywhere in the memory space. I mean, in some cases you could have them in contiguous memory, but how will you identify such cases in compile time? Depending on the caller, and depending on the run time path the program takes, the outcome could be different. For instance, even if there is only one caller, and that caller iterates through a list to allocate objects on the heap for the linked list, there is no guarantee that the OS (or the run-time library) will give you contiguous memory blocks. cheers, --renato