similar to: [LLVMdev] Artificial deps and stores

On Jan 17, 2014, at 4:03 PM, Andrew Trick <atrick at apple.com> wrote: > > On Jan 17, 2014, at 3:54 PM, Hal Finkel <hfinkel at anl.gov> wrote: > >> Andy, et al., >> >> In ScheduleDAGInstrs::buildSchedGraph, the code for handling stores has this: >> >> if (!ExitSU.isPred(SU)) >> // Push store's up a bit to avoid them

Hello again, Sorry -- I think I found the problem somewhere else. I was a bit confused and missed the fact that adjustChainDeps() is called a few lines down and does just what I wanted :-) I would like to instead ask another question: Why is I->isCtrl() used in code like // Iterate over chain dependencies only. for (SUnit::const_succ_iterator I = SUb->Succs.begin(), E =

Hi, Can anyone help me to understand the ScheduleDAGInstrs::buildSchedGraph() method? I find the handling of AliasChain is disturbing since: 1. A new alias chain add deps to all possibly aliasing SUs, and then clears those lists. 2. When AliasChain is present, the addChainDependency() method is called, but the target hook areMemAccessesTriviallyDisjoint() called inside

Hi, Thank you for the reply. >It looks to me like we can choose any subset of edges here and be correct. We're basically trying to prune/pinch the DAG edges here. They can easily blow up with AA sched. I would guess that isCtrl() edges are good ones to bypass because they could be a low-latecy edges, whereas true data dependencies from a load are expected to be >higher latency, so they

Andy, I traced my problem to this point: In ScheduleDAGInstrs.cpp we have the following function: /// addVRegDefDeps - Add register output and data dependencies from this SUnit /// to instructions that occur later in the same scheduling region if they read /// from or write to the virtual register defined at OperIdx. /// /// TODO: Hoist loop induction variable increments. This has to be ///

On Jun 13, 2012, at 10:49 AM, Sergei Larin <slarin at codeaurora.org> wrote: > So if this early exit is taken: > > // SSA defs do not have output/anti dependencies. > // The current operand is a def, so we have at least one. > if (llvm::next(MRI.def_begin(Reg)) == MRI.def_end()) > return; > > we do not ever get to this point: > >

Andy, Thanks for reply. I was able to trace the problem to the MI DAG dep constructor. See this: SU(0): %vreg1<def> = COPY %vreg10<kill>; IntRegs:%vreg1,%vreg10 # preds left : 0 # succs left : 0 # rdefs left : 1 Latency : 1 Depth : 0 Height : 0 SU(1): %vreg10<def> = LDriw %vreg9<kill>, 0;

On Mar 29, 2012, at 1:18 PM, Tom Stellard <thomas.stellard at amd.com> wrote: > 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

Hi, I am trying to add Hazard scheduling nodes after buildSchedGraph(), with a scheduler derived from ScheduleDAGInstrs. I get weird errors, so I wonder what I am doing wrong? What I am doing right now is: I have a created MI with opcode HAZARD that does not have parent, and I greate a SUnit(HazardMI). I use this one HazardMI for all hazard nodes. I remove all edges using removePred. I insert

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

On Feb 21, 2013, at 9:11 AM, Jonas Paulsson <jonas.paulsson at ericsson.com> wrote: > Hi, > > I am trying to add Hazard scheduling nodes after buildSchedGraph(), with a scheduler derived from ScheduleDAGInstrs. I get weird errors, so I wonder what I am doing wrong? > > What I am doing right now is: > > I have a created MI with opcode HAZARD that does not have

Hi Andy, The thing is that I was trying to build a sched graph in other places than these two standard scheduling passes. For instance, in pre-emit. I would like to reschedule a basic block on my vliw target just before assembly emission. I tried to add SUnits for hazards in an experiment, but this gave very weird errors... even while allocating extra space in SUnits vector. For some function, I

> Please try it out, run tests, build your favourite projects and file > bugs about anything that needs to be fixed, marking them as blockers > of http://llvm.org/pr31622. I have encountered very long compile times for three large source files containing generated/unrolled code at -O1. We are talking about 10+ hours here without completing, so it looks very much like an endless loop. The

Andy, You are probably right here - look at this - before phi elimination this code looks much more sane: # *** IR Dump After Live Variable Analysis ***: # Machine code for function push: SSA Function Live Outs: %R0 BB#0: derived from LLVM BB %entry %vreg5<def> = IMPLICIT_DEF; IntRegs:%vreg5 %vreg4<def> = TFRI_V4 <ga:@xx_stack>; IntRegs:%vreg4

Hi Tom, Thanks a lot for your explanations, now it makes a lot more sense ;) I had a slightly closer look at the R600 packetizer, and the issue is that the third LSHL instruction has both an implicit use and *afterwards* an implicit def of T1_XYZW. The latter def causes the current ScheduleDAGInstrs implementation to ignore the implicit use, thus the ScheduleDAG only contains an

Hi, I have revisited the issue in buildSchedGraph() I talked about previously, and attached a few patches. The first tries to fix the issue, and the other two try to illustrate associated issues, emerged from applying it. Is it OK to commit the first patch? [PATCH] Bugfix for missed dependency from store to load in buildSchedGraph(). Bugfix for missed dependency from store to load in

Hello, The ScheduleDAGInstrs::buildSchedGraph() function creates def/uses lists by iterating over all instruction operands and calls addPhysRegDeps() if used post-RA (line ~770 ff.). If an operand is a def, the uses of that registers are cleared (ScheduleDAGInstrs.cpp:333: Uses.eraseAll(Reg); ). As a consequence, if an instruction has an explicit use of a register and an implicit def of the

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

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

Hi, (This only concerns MISNeedChainEdge(), and is separate from D8705) I found out that the MIScheduler (pre-ra) could not handle a simple test case (test/CodeGen/SystemZ/alias-01.ll), with 16 independent load / add / stores. The buildSchedGraph() put too many edges between memory accesses, because 1) There was no implementation of areMemAccessesTriviallyDisjoint() for SystemZ. 2) Type