similar to: [LLVMdev] Available code-generation parallism

On Nov 2, 2008, at 2:20 PM, Jonathan Brandmeyer wrote: > I am interested in making my LLVM front-end multi-threaded in a way > similar to the GCC compiler server proposal and was wondering about > the > extent that the LLVM passes support it. Do you have a link for this? I'm not familiar with any parallelism proposed by that project. My understanding was that it was mostly

On Mon, 2008-11-03 at 01:06 -0800, Chris Lattner wrote: > On Nov 2, 2008, at 2:20 PM, Jonathan Brandmeyer wrote: > > I am interested in making my LLVM front-end multi-threaded in a way > > similar to the GCC compiler server proposal and was wondering about > > the > > extent that the LLVM passes support it. > > Do you have a link for this? I'm not familiar

On 3 Nov., 10:06, Chris Lattner <clatt... at apple.com> wrote: > On Nov 2, 2008, at 2:20 PM, Jonathan Brandmeyer wrote: > > > I am interested in making my LLVM front-end multi-threaded in a way > > similar to the GCC compiler server proposal and was wondering about   > > the > > extent that the LLVM passes support it. > > Do you have a link for this?

On Mon, 2008-11-03 at 23:59 -0800, Chris Lattner wrote: > On Nov 3, 2008, at 3:55 PM, heisenbug wrote: > > What about "inventing" pseudo-constants (which point to the right > > thing) and build the piece of IR with them. When done, grab mutex and > > RAUW it in. Alternatively, submit to a privileged thread that performs > > the RAUW. > > The trick is to

On Nov 6, 4:22 am, Jonathan Brandmeyer <jbrandme... at earthlink.net> wrote: > On Mon, 2008-11-03 at 23:59 -0800, Chris Lattner wrote: > > On Nov 3, 2008, at 3:55 PM, heisenbug wrote: > > > What about "inventing" pseudo-constants (which point to the right > > > thing) and build the piece of IR with them. When done, grab mutex and > > > RAUW it

On Nov 3, 2008, at 3:55 PM, heisenbug wrote: > What about "inventing" pseudo-constants (which point to the right > thing) and build the piece of IR with them. When done, grab mutex and > RAUW it in. Alternatively, submit to a privileged thread that performs > the RAUW. > The trick is to prepare the def/use chain(s) to a degree that the > mutex is only held a minimal

> I don't understand why you want to factor out the information, > exactly. It seems like what you need is a function like: > > unsigned getMinLeadingZeros(const SCEV *); > > then, if you want to get the non-extended expression, you can just > apply an appropriate truncation. I assume, however, that I'm missing > something. The problem is not about how to codegen

While I think the end goal you're describing is close to the correct one, I see the high-level strategy for getting there somewhat differently: 1) The code generators are only one collection of function passes that might be parallelized. Many others might also be parallelized profitably. The design for parallelism within LLVM's pass management infrastructure should be sufficiently generic

Hi, community: For the sake of our business need, I want to enable "Function-based parallel code generation" to boost up the compilation of single module, please see the details of the design and provide your feedbacks on below aspects, thanks! 1. Is this idea the proper solution for my requirement 2. This new feature will be enabled by llc -thd=N and has no impact on original llc when

I've been playing around with llvm lately and I was wondering something about the bitcode instructions for basic arithmetic. Is there any plan to provide instructions that perform widening multiply, or add with carry? It might be written as: mulw i32 %lhs %rhs -> i64 ; widening multiply addw i32 %lhs %rhs -> i33 ; widening add addc i32 %lhs, i32 %rhs, i1 %c -> i33 ; add with carry

Hi Javed, On 06/18/10 14:07, Javed Absar wrote: > 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

This is related to an issue in loop strength reduction [1] that I've been trying to fix on and off for a while. [1] has a more detailed description of the issue and an example, but briefly put, I want LSR to consider formulae that have "Zext T" as base and/or scale registers, and to appropriately rate such formulae. My first attempt[2] at fixing this was buggy and had to be

On 10/27/10 8:34 PM, Eli Friedman wrote: > On Wed, Oct 27, 2010 at 1:29 PM, Brian West<bnwest at rice.edu> wrote: >> Here is the patch for the new Operator Strength Reduction optimization >> pass that I have written. The bulk of the code is in >> >> lib/Transforms/Scalar/OperatorStrengthReduce.cpp >> >> The algorithm finds reduction opportunities in

On Thu, Oct 28, 2010 at 9:38 AM, Brian West <bnwest at rice.edu> wrote: >> 3. LLVM already has a significant amount of infrastructure for loop >> passes; why does this pass have its own code for finding loops? > > I saw the loop infrastructure for CFG loops. This algorithm finds loops in > the data flow (more precisely: strongly-connected components in the >

That solves the issue but it seems odd to me that instcombine doesn't take care of it? So is this just a setup for the backend? If not, seems like if there is a possibility that lsr could create these redundant operations, should it not clean itself up? Or am I mistaken? On Fri, Oct 19, 2012 at 1:29 PM, Andrew Trick <atrick at apple.com> wrote: > > On Oct 17, 2012, at 1:22 PM,

Ok, thanks. Even still though I would expect -instcombine (run after lsr) would do this cleanup? On Fri, Oct 19, 2012 at 2:41 PM, Andrew Trick <atrick at apple.com> wrote: > > On Oct 19, 2012, at 2:34 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > That solves the issue but it seems odd to me that instcombine doesn't take > care of it? > > > LSR is

On Mon, 2007-12-03 at 18:56 -0800, Chris Lattner wrote: > Other IR objects (like instructions) have very simple ownership. An > instruction is owned by its basic block, a bb is owned by the function, a > function is owned by thet module. If an instruction is initially allocated with its Instruction *insertAtEnd parameter defaulted to null, and then later appended to a BasicBlock,

On Oct 19, 2012, at 2:44 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Ok, thanks. > > Even still though I would expect -instcombine (run after lsr) would do this cleanup? It's valid to run any IR pass after -loop-reduce. So you can try it. -gvn is probably what you're looking for. It isn't something we normally want to do. Turn off LSR if it does bad things on

On Wed, Oct 27, 2010 at 1:29 PM, Brian West <bnwest at rice.edu> wrote: > Here is the patch for the new Operator Strength Reduction optimization > pass that I have written.  The bulk of the code is in > > lib/Transforms/Scalar/OperatorStrengthReduce.cpp > > The algorithm finds reduction opportunities in both array accesses and > explicit multiplications within loops.

On Oct 19, 2012, at 2:34 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > That solves the issue but it seems odd to me that instcombine doesn't take care of it? LSR is part of the backend. It's lowering the IR for a specific target. It seems to think those redundant operations are good for reducing register pressure, but doesn't actually have much knowledge about register