similar to: [LLVMdev] Speculative paralellisation in LLVM compiler infrastructure!!!!!

Please cc llvm-dev in replies to llvm-dev emails. On 11 October 2011 10:31, Muthu Raj <sameer.muthu9 at gmail.com> wrote: > > Hi Nick, > Thanks for your reply.Now i need some help about how can i > proceed to start writing a patch for acheiving paralellisation in llvm. > Great! I am new to open source and llvm. So please dont mind if my questions are >

Hi all, I'm organizing a BoF session during the upcoming EuroLLVM developers meeting. As the subject of this message already shows, this session will be on compilers in education. I'm currently looking for both participants to the discussion and input for the actual program of the session. I've already got some ideas which I'll introduce below. At our university, we mostly

Hi: I worked on loop-optimizations techniques previously using ORC. Currently i see lots of research on speculative parallelization of loops ... specially because multicores [for embedded systems] is becoming popular. In other words, because you have multiple cores, you can start some loops [Fast-Track] as if there is no or low data-dependence [Partial Parallel Loop-Nest]. The normal part is to

On 06/21/10 07:12, Javed Absar wrote: > Hi Tobias: > Thanks for replying . So if I understand correctly, in LLVM currently, > the Polyhedral model is being built ( LLVM IR -------> Poly Model > ----------> LLVM IR ). > This is for compile-time optimizations of loop-nests [e.g. > loop-transformations to expose parallelism or improve locality etc]. > Yes, thats great for

On Mon, Jun 21, 2010 at 10:27 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > On Mon, Jun 21, 2010 at 1:12 AM, Javed Absar <javed.absar at gmail.com> wrote: >> Hi Tobias: >> >> Thanks for replying . So if I understand correctly,  in LLVM currently, the >> Polyhedral model is being built ( LLVM IR -------> Poly Model ----------> >> LLVM IR ).

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 1 Hi Alexandra, Can you guarantee that the linked list will be allocated in contiguous memory? cheers, --renato

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

At some point while browsing the LLVM web site, I stumbled across a paper that discussed using LLVM with an analysis technique that used dataflow analysis and generated speculative data for code. They used the technique on binutils and found a number of errors in that package. Does anyone recall the specific paper/system so that I can revisit it? I tried a number of google searches but I keep

On Mon, 18 Jun 2012 15:15:13 MDT, Richard <legalize at xmission.com> wrote: > Does anyone recall the specific paper/system so that I can revisit it? Of course, I stumble across it as soon as I posted the message... KLEE is what I was remembering: <http://klee.llvm.org/GetStarted.html> -- "The Direct3D Graphics Pipeline" free book

I wanted to generate code for ia64 machine with instructions such as speculative load(ld.s) and checks(chk.s) using llvm .Does the LLVM currently uses these instructions when generating code for ia64?.If not how to generate code using these instructions? Unnikrishnan C -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

On Mon, Jun 21, 2010 at 1:12 AM, Javed Absar <javed.absar at gmail.com> wrote: > Hi Tobias: > > Thanks for replying . So if I understand correctly,  in LLVM currently, the > Polyhedral model is being built ( LLVM IR -------> Poly Model ----------> > LLVM IR ). > This is for compile-time optimizations of loop-nests [e.g. > loop-transformations to expose parallelism

Hi, On Fri, Jun 4, 2010 at 5:18 AM, Pekka Nikander <pekka.nikander at nomadiclab.com> wrote: >  Would the best way be to add an option to -loop-unroll, and hack away at lib/Transforms/Utils/LoopUnroll.cpp? Instead, the better alternative is to write another pass similar to LoopUnrollPass.cpp (say LoopPeelPass.cpp) and add new option -loop-peel. The new pass could use llvm::UnrollLoop()

On Fri, Jun 4, 2010 at 8:18 AM, Pekka Nikander <pekka.nikander at nomadiclab.com> wrote: > I am working on heavily optimising unusually static C++ code, and have encountered a situation where I basically want an optimiser that would speculatively unroll a loop to see if the first round of the loop could be optimised further.  (I happen to know that it is possible.)  The previous

Hi, Has something related to speculative tracing changed between s10 FCS and the more recent nevada builds ? I was trying the specopen.d script from the Dtrace guide on a nevada machine and it failed with : dtrace: failed to enable ''./spec.d'': DIF program content is invalid To try and narrow things down a bit I wrote the following short script. This works fine on s10, but

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

On 31 July 2013 11:56, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > The slightly orthogonal question to safety is the cost of execution. For > most intrinsics that represent CPU instructions, executing them > speculatively is cheaper than a conditional jump, but this is not the case > for all (for example, some forms of divide instructions on in-order RISC >

Hi, There are several optimizations where we try to load speculatively. There are also two similar functions to determine whether it's a safe transformation: * isSafeToLoadUnconditionally * isSafeToSpeculativelyExecute isSafeToLoadUnconditionally tries to take load alignment into account but fails to do this in some cases. It checks alignment for pointers derived from allocas and global

On 07/19/2011 11:12 AM, Jimborean Alexandra wrote: > Hi Tobi, > > Thank you for your reply :). > > I know that array accesses are handled as pointers in LLVM, but as I > understood Polly is focused on statically analysable code. As you > mentioned: proving that pointer accesses actually represent virtual > array accesses. > [...] > > Is this approach going to work

Hi, A few days ago I stumbled upon a problem where SpeculativeExecution changed the order of a load and a store to the same address. I wrote https://bugs.llvm.org//show_bug.cgi?id=32964 about it but no response there so far. In the input we have store i8 0, i8* @i %.pre = load i8, i8* @i and then in the output the load is moved so it's before the store which clearly makes it

On 07/18/2011 07:03 PM, Jimborean Alexandra wrote: > Hi, > > I plan to do some speculative parallelization in LLVM using Polly and I > target loops that contain pointers and indirect references. As far as I > know, Polly generates optimized code starting from the SCoPs, therefore > I plan to replace all pointer accesses with array accesses, such that > Polly will accept the