similar to: [LLVMdev] alias analysis in ScheduleDagInstr class

Hi Sergei, thanks for considering my question. We if-convert some code, such that the basic block looks as follows after if-conversion: ld char from A into R1 p1 = R1>255? (generate the predicate) p1 | R1 = 255 (conditional execution) st char R1 to A ld char from A+1 into R2 p2 = R2>255? (generate the predicate) p2 | R2 = 255 (conditional execution) store char R2 to A+1 The problem is

We observed exact same problem, and I did put in place a mechanism to recognize and break such false dependencies right before pre-RA scheduler (in DAG->DAG lowering), but the immediate observed effect for our back end was performance reduction, since none of the current schedulers were capable of dealing with newly presented parallelism in BB (resulted in high reg pressure and

I am working on something very(very) similar, what is the exact nature of your question? Sergei Larin -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Bjorn De Sutter Sent: Friday, November 11, 2011 7:59 AM To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] alias

Hi all, I am working on a CGRA backend (something like a 2D VLIW), and we also absolutely need predication. I extended the IfConversion pass to allow it to be executed multiple times and to predicate already predicated code. This is necessary to predicate code with nested conditional statements. At this point, we support or, and, and conditional predicates (see Scott Mahlke's papers on this

On Thu, Mar 29, 2012 at 01:50:58PM -0500, Sergei Larin wrote: > Tom, > > What is in your isSchedulingBoundary? If it contains isLabel you might > need to disable that assert: > > assert(!MI->isTerminator() && !MI->isLabel() && > "Cannot schedule terminators or labels!"); > > Sergei Larin > > -- > Qualcomm

On Aug 9, 2012, at 10:09 AM, Sergei Larin <slarin at codeaurora.org> wrote: > Yang, > > This might not be such a tough choice on engineering side - one of the > LLVM differentiators is the ground-up, early introduced support for VLIW > specific features… Actually, LLVM lacked support for VLIW until fairly recently, and it has relatively few VLIW-specific features. Dan

Tom, I do not have your call stack, but packetizer calls ScheduleDAGInstrs::buildSchedGraph to create dependency model. If this is the first time you use the new MI sched infrastructure (like your target has not implemented misched yet) there might be some work needed to implement couple target hooks. isSchedulingBoundary is one of them. Also try to disable that assert and see what happens. It

Larin, Thank you for telling me about this. Our lab is planning to design a VLIW DSP and has to make a choice between GCC and LLVM, for which I take responsibility. As we all know that GCC's codes possess a long history and has a somewhat bad learning curve, I suggest choosing LLVM. It seems now the only drawback is its poor support for VLIW architecture. And so if we can count on

Hi all, in r152019 (from ctopper), the number of available registers of any type in a machine description is decreased to 256 because it needs to be encoded in uint8_t now. I'm trying to support an experimental embedded architecture with more registers (out of tree), but now that becomes impossible. Anyone knows a solution? Thanks, Bjorn De Sutter Computer Systems Lab Ghent University

But we are really striving to change it fast :) Dan, My comparative point was that LLVM has a greater potential to accommodate VLIW going forward than GCC does at this point. Would you agree to that? Sergei -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. > -----Original Message----- > From: Dan Gohman [mailto:gohman at apple.com] > Sent: Friday, August 10,

On Feb 11, 2013, at 1:03 PM, Sergei Larin <slarin at codeaurora.org> wrote: > Hi Andy, > > I have to resurrect an ancient question regarding scheduling boundaries. > > You might remember the reason for introduction of CanHandleTerminators to > ScheduleDAGInstrs. In short, Hexagon is currently uses DAG construction > method (buildSchedGraph) for several purposes,

On Thu, Mar 29, 2012 at 02:57:27PM -0500, Sergei Larin wrote: > Tom, > > I do not have your call stack, but packetizer calls > ScheduleDAGInstrs::buildSchedGraph to create dependency model. If this is > the first time you use the new MI sched infrastructure (like your target has > not implemented misched yet) there might be some work needed to implement > couple target

Sergei, I would say that each target has its own scheduling strategy that has changed considerably over time. We try to maximize code reuse across targets, but it's not easy and done ad hoc. The result is confusing code that makes it difficult to understand the strategy for any particular target. The right thing to do is: 1) Make it as easy as possible to understand how scheduling works for

Hi all, I'd recommend Andy Trick be made code owner of "instruction scheduling" (including MI, pre-RA, and post-RA schedulers). I am also recommending Nadav Rotem be made code owner of "loop vectorizer". Evan

Hi, It seems the only one VLIW target Hexagon in LLVM 3.2 devel uses a straightforward way to emit its VLIW-style asm codes. It uses a list scheduler to schedule on DAG and a simple packetizer to wrap the emitted asm instructions. Both scheduling and packetizing work on basic blocks. so, is there any plan to implement better optimization methods such as trace scheduling, software pipelining, ...

On Wed, Oct 31, 2012 at 09:13:43PM +0100, Bjorn De Sutter wrote: > Hi all, > > I am working on a CGRA backend (something like a 2D VLIW), and we also absolutely need predication. I extended the IfConversion pass to allow it to be executed multiple times and to predicate already predicated code. This is necessary to predicate code with nested conditional statements. At this point, we

On Nov 13, 2012, at 2:59 PM, Evan Cheng <evan.cheng at apple.com> wrote: > Hi all, > > I'd recommend Andy Trick be made code owner of "instruction scheduling" (including MI, pre-RA, and post-RA schedulers). I am also recommending Nadav Rotem be made code owner of "loop vectorizer". Sergei Larin can take ownership of VLIW scheduling. Most of the support

Sergei Larin <slarin at codeaurora.org> writes: > - We do need to have a way to assign bundles much earlier than we do now. Yeah, I can imagine why this would be useful. > And it needs to be intertwined with scheduling (Bundler currently reuses a > good chunk of scheduler infrastructure). Just to clarify, is the need due to the current bundling implementation of reusing

Yang, There is work currently underway to add SW pipelining and some sort of global scheduling to Hexagon, but if there is some interest to it from other targets, it would be helpful to know. What is your involvement with this? Sergei Larin -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu

I changed it to uint16_t in r152100. Is that enough for your architecture? On Tue, Mar 6, 2012 at 12:24 AM, Bjorn De Sutter < bjorn.desutter at elis.ugent.be> wrote: > Hi all, > > in r152019 (from ctopper), the number of available registers of any type > in a machine description is decreased to 256 because it needs to be encoded > in uint8_t now. I'm trying to support an