search for: buildschedgraph

...drew Trick [mailto:atrick at apple.com] Sent: den 10 februari 2015 22:12 To: Jonas Paulsson Cc: Hal Finkel; Mattias Eriksson V; llvmdev at cs.uiuc.edu; Tom Stellard; Sergei Larin; Patrik Hägglund H; Sanjin Sijaric; llvm commits Subject: Re: [PATCH] Bugfix for missed dependency from store to load in buildSchedGraph(). On Feb 10, 2015, at 6:54 AM, Jonas Paulsson <jonas.paulsson at ericsson.com<mailto:jonas.paulsson at ericsson.com>> wrote: Looking at the possibility of refactorization / redesign, I wonder what are the main strong points of this implementation right now, in your opinion? The mapp...

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(). Bu...

...Sent: den 7 februari 2015 02:07 To: Jonas Paulsson Cc: Mattias Eriksson V; llvmdev at cs.uiuc.edu; Tom Stellard; Sergei Larin; Patrik Hägglund H; Sanjin Sijaric; Andrew Trick (atrick at apple.com); llvm-commits at cs.uiuc.edu Subject: Re: [PATCH] Bugfix for missed dependency from store to load in buildSchedGraph(). ----- Original Message ----- > From: "Jonas Paulsson" <jonas.paulsson at ericsson.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "Sanjin Sijaric" <ssijaric at codeaurora.org>, "Andrew Trick (atrick at apple.com)" > <atrick at...

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 Based Alias Analysis (TBAA) was not used. I have gotten rid of the edges on an experimental level, and would now like some help and feedback: 1): It see...

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 instructions and any terminators, including labels (though I know it sounds strange). Nevertheless, ScheduleDAGInstrs::buildSchedGraph still has this hard assert...

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 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 >> dis...

...odeaurora.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, which includes region > formation for general VLIW packetization/bundling. As such we need to handle > pretty much all instructions and any terminators, including labels (though I > know it sounds strange). Nevertheless, ScheduleDAGInstrs::buildSchedGraph > still...

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 hooks. isSchedulingBoundary is one of them. Also try to > disable that assert...

...e frame index operands of the first two stores and the fourth load have been lowered to real addresses. Since the first two SWs store to ($sp + 44) and ($sp + 40), and instruction LDC1 loads from ($sp + 40), there should be a dependency between these instructions. However, when ScheduleDAGInstrs::BuildSchedGraph(AliasAnalysis *AA) builds the schedule graph, there are no dependency edges added between the two SWs and LDC1 because getUnderlyingObjectForInstr returns different objects for these instructions: underlying object of SWs: FixedStack-1 underlying object of LDC1: struct.ObjPointStruct* %P Is this...

...gBoundary to check if an instruction is a scheduling boundary or not. If it is a scheduling boundary, all existing instructions in the region are scheduled and next region is started. By default, isSchedulingBoundary returns true for labels and terminator instructions. Further, there is a check in BuildSchedGraph (I think) that asserts if it finds labels or terminator. I think that assert should be changed to use isSchedulingBoundary API. Another problem for VLIW machines is packetization of terminator instruction with other instructions. For example, Hexagon allows to packetize terminators with others if...

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 getting in between cmp // and branches. ExitSU.addPred(SDep(SU, SDep::Artificial)); This code does not seem to be in any way specific to compares; and in any ca...

...mplicit-defs alone has no effect in this example, as then the implicit-use of T1_XYZW is then no longer removed and a true dependency to the def of T1_W is added. Removing all implicit operands however solves that (see attached patch/hack). I would argue that the behaviour of ScheduleDAGInstrs::buildSchedGraph for implicit operands is not correct, simply because changing the order of the operands would already prevent the R600 packetizer from bundling in this example. Cheers, Stefan On 2014-02-25 17:35, Tom Stellard wrote: > On Tue, Feb 25, 2014 at 04:38:46PM +0100, Stefan Hepp wrote: >>...

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 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 getting in between cmp >> // and branches. >> ExitSU.addPred(SDep(SU, SDep::Artificial)); >> >> This code does not se...

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 exp...

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 edg...

...first two stores and the fourth load > have been lowered to real addresses. > Since the first two SWs store to ($sp + 44) and ($sp + 40), and > instruction LDC1 loads from ($sp + 40), > there should be a dependency between these instructions. > > However, when ScheduleDAGInstrs::BuildSchedGraph(AliasAnalysis *AA) > builds the schedule graph, > there are no dependency edges added between the two SWs and LDC1 because > getUnderlyingObjectForInstr returns different objects for these instructions: > > underlying object of SWs: FixedStack-1 > underlying object of LDC1: struc...

...implement alias analysis in my backend. I would like to for example get the result that two stack-accesses with different offsets (indexes), would return noAlias. However, I'm somewhat confused as there is no notion of offset for the Location object. I would also like to call ScheduleDAGInstr::buildSchedGraph() with this AliasAnalysis and have MIsNeedsChainEdge() return false in this case. What should I do? Adding a MemoryOperand to such an instruction seems right, but it doesn't seem to fit quite. What Value would be referenced? BasicAliasAnalysis returns MustAlias for the same Value, e g 'Sta...

...e fourth load >> have been lowered to real addresses. >> Since the first two SWs store to ($sp + 44) and  ($sp + 40), and >> instruction LDC1 loads from ($sp + 40), >> there should be a dependency between these instructions. >> >> However, when ScheduleDAGInstrs::BuildSchedGraph(AliasAnalysis *AA) >> builds the schedule graph, >> there are no dependency edges added between the two SWs and LDC1 because >> getUnderlyingObjectForInstr returns different objects for these instructions: >> >> underlying object of SWs: FixedStack-1 >> underlyin...

...t; 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 target has > >> not implemented misched yet) there might be some work needed to implement > >> couple target hooks. isSchedulingBoundary is one of them. Also try...