similar to: [LLVMdev] Code Owner nominations

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, Thank you for your attention. My target is a custom VLIW DSP. I am not sure dependency dag is correct when it gets scheduled and packetized. Months ago, I submitted a bug at http://llvm.org/bugs/show_bug.cgi?id=17894 which explained more details. I am not sure my understanding of this bug is proper, but modified my local codes this way and it works for my target when scheduling and

Hi, I'm working on a custom top-down post RA scheduler which builds bundles at the same time for our VLIW processor. I've borrowed most of the implementation from the resource priority queue implemented for the existent VLIW scheduler but applied to the context of MI scheduling. Basically, instructions that are likely to be bundled must be scheduled first (i.e. get higher priority).

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, 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 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,

My 2c... Even though I understand it might be way off in the future, but we are talking about long term plans here anyway. Also as a VLIW backend maintainer, I just have to say it :) - We do need to have a way to assign bundles much earlier than we do now. And it needs to be intertwined with scheduling (Bundler currently reuses a good chunk of scheduler infrastructure). It is also obvious

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

Hi all, Thanks for your feed-backs :-) @Andrew: In fact, I've reused most of the postRA list scheduler code and the resource priority queue. Every time it needs to move forward, either because of a res hazard (HazardRec) or an invalid combination of instructions in the current packet (DFA), it closes the current bundle and advances to the next cycle. The non-interlocked nature of our

Hi, all, When I schedule machine instructions in a VLIW way and packetize them, a problem is encountered, and I will show it use a simplified case as follows. ############ original instruction sequence ... insn1 ... jump LBB0_xx ... LBB0_xx: ... ############ expected instruction sequence after scheduling and packetizing insn1; jump LBB0_xx ... LBB0_xx: ... ############ generated instruction

Hello everyone, I am working on some changes to the Hexagon VLIW PreRA scheduler, and as a part of it need to test aliasing properties of two instruction. What it boils down to is the following code: char a[20]; char s; char *p, *q; // p == &a[0]; q == &s; void test() { register char reg; s = 0; reg = p[0] + p[1]; s = q[0] + reg; return; } When I ask the question whether

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

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

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

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 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, which includes region formation for general VLIW packetization/bundling. As such we need to handle pretty much all

On Thu, 10 May 2012 20:33:53 -0700 Andrew Trick <atrick at apple.com> wrote: > On May 9, 2012, at 8:34 AM, dag at cray.com wrote: > > > Andrew Trick <atrick at apple.com> writes: > > > >>> When I asked about enhancing scheduler heuristics a month or so > >>> ago, I got a response about a MachineInstr scheduler and that > >>> that

Dave, Thank you for your interest. Please see my replies below. Sorry that my terminology is not as crisp as Andy's, but I think you can see what I mean. Sergei -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. > -----Original Message----- > From: dag at cray.com [mailto:dag at cray.com] > Sent: Friday, May 11, 2012 12:14 PM > To: Sergei Larin > Cc:

On Feb 8, 2013, at 12:28 PM, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote: > On 02/08/2013 08:20 PM, Tobias Grosser wrote: >> That sounds elegant and seems to solve the correctness problems. > > There is no big difference here except that the memory instructions > would not need the metadata. > > I do not think the abundance of metadata is really the

On Thu, Mar 1, 2012 at 1:04 PM, Sergei Larin <slarin at codeaurora.org> wrote: > Hello everyone, > >  I am working on some changes to the Hexagon VLIW PreRA scheduler, and as a > part of it need to test aliasing properties of two instruction. > What it boils down to is the following code: > > char a[20]; > char s; > char *p, *q; // p == &a[0]; q == &s; >