search for: scoreboardhazardrecogn

Hello. I am new to the schedulers implemented in the back end of LLVM. I am trying to handle data hazards in my simple processor, with instructions that execute in 1 cycle. I have tried the standard post-RA scheduler, implemented in lib/CodeGen/PostRASchedulerList.cpp, (with a ScoreboardHazardRecognizer), but I have some issues with some consecutive instructions that are separated in the final ASM listing and they should not. I also tried the standard pre-RA scheduler, implemented in lib/CodeGen/ScheduleDAGRRList.cpp, (with a ScoreboardHazardRecognizer), but even if I report that I h...

...ype HT = HazardRec->getHazardType(CurSUnit, 0/*no stalls*/); Let me state what I have added to my back end to enable scheduling with hazards: - inspiring from lib/Target/PowerPC/PPCHazardRecognizers.h, I have created a class [Target]DispatchGroupSBHazardRecognizer : public ScoreboardHazardRecognizer (I use ScoreboardHazardRecognizer because I hope in the near future to make my class employ in "out-of-order" execution USEFUL program instructions instead of NOP to handle my data hazards), implementing for it only a method: HazardType getHazardType(SUnit *SU, int St...

Hello. I am progressing a bit with difficulty with the post RA scheduler (PostRASchedulerList.cpp with ScoreboardHazardRecognizer) - the problem I have is that it doesn't advance at the next available instruction when the overridden ScoreboardHazardRecognizer::getHazardType() method returns NoopHazard and it gets stuck at the same instruction (store in my runs). Just to make sure: I am trying to use the post-R...

...C, now that Hybrid > > scheduling is enabled, EmitInstruction seems never to be called (at > > least it is not called when running any PPC codegen test in the > > regression-test collection). > > > Hal, > > > Since PPCHazardRecognizer is not derived from > ScoreboardHazardRecognizer, you'll need to initialize MaxLookAhead to > the max depth of your target's itinerary. Andy, Thanks! Since I have to change PPCHazardRecognizer for bottom-up support anyway, is there any reason not to have it derive from ScoreboardHazardRecognizer at this point? It looks like the c...

...gt; I feel that I should clarify my comment: For PPC, now that Hybrid > scheduling is enabled, EmitInstruction seems never to be called (at > least it is not called when running any PPC codegen test in the > regression-test collection). Hal, Since PPCHazardRecognizer is not derived from ScoreboardHazardRecognizer, you'll need to initialize MaxLookAhead to the max depth of your target's itinerary. See how this is done in the ScoreboardHazardRecognizer ctor: > MaxLookAhead = ScoreboardDepth; -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http...

Hello. Hal, thank you for the information. I managed to get inspired from PPCHazardRecognizers.cpp. So I created my very simple [Target]HazardRecognizers.cpp pass that is also derived from ScoreboardHazardRecognizer. My class only implements the method getHazardType(), which checks if, as stated in my first email, for example, I have a store instruction that is storing the value updated by the instruction immediately above, which is NOT ok, since for my processor this is a data hazard and in this case...

...ling also account > > >> > > >> ARM is a good model. > > > > > > What part of ARM's implementation is associated with the bottom-up > > > scheduling? I am confused because it looks like it is essentially using > > > the same kind of ScoreboardHazardRecognizer that was commented out of > > > the PPC 440 code. > > > > > > Thanks in advance, > > > Hal > > > > Hi Hal, > > > > The best way to ensure the PPC scheduling isn't hosed now or in the > > future is probably to make it work...

...abled, EmitInstruction seems never to be called (at > > > least it is not called when running any PPC codegen test in the > > > regression-test collection). > > > > > > Hal, > > > > > > Since PPCHazardRecognizer is not derived from > > ScoreboardHazardRecognizer, you'll need to initialize MaxLookAhead to > > the max depth of your target's itinerary. > > Andy, > > Thanks! Since I have to change PPCHazardRecognizer for bottom-up support > anyway, is there any reason not to have it derive from > ScoreboardHazardRecognizer...

...ncing at the code. FWIW, I'm hoping it can be cleaned up gradually, maybe for the next release. The preRA scheduler is bottom-up, for register pressure tracking. The postRA scheduler is top-down, for simpler hazard detection logic. On ARM, the preRA scheduler uses an unspecialized instance of ScoreboardHazardRecognizer. The machine-independent RecedeCycle() logic that operates on the scheduler itinerary is sufficient. The ARM postRA scheduler specializes the HazardRecognizer to handle additional constraints that cannot be expressed in the itinerary. Since this is a top-down scheduler, RecedeCycle() is no app...

...ry client). If you can do the same with PPC that's great. Andy On Nov 29, 2011, at 8:51 AM, Hal Finkel <hfinkel at anl.gov> wrote: >> Thanks! Since I have to change PPCHazardRecognizer for bottom-up support >> anyway, is there any reason not to have it derive from >> ScoreboardHazardRecognizer at this point? It looks like the custom >> bundling logic could be implemented on top of the scoreboard recognizer >> (that seems similar to what ARM's recognizer is doing). > > Also, how does the ARM hazard recognizer get away with not implementing > RecedeCycle? >...

...PPC that's great. > > Andy > > On Nov 29, 2011, at 8:51 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > >> Thanks! Since I have to change PPCHazardRecognizer for bottom-up support > >> anyway, is there any reason not to have it derive from > >> ScoreboardHazardRecognizer at this point? It looks like the custom > >> bundling logic could be implemented on top of the scoreboard recognizer > >> (that seems similar to what ARM's recognizer is doing). > > > > Also, how does the ARM hazard recognizer get away with not implementing &g...

...ntains legacy support for itineraries. This is // required until SD and PostRA schedulers are replaced by MachineScheduler. This poses several question as to: 1) which representation gives the better cost estimation? 2) AFAIK, MachineScheduler can also take advantage from InstrItineraries with the ScoreboardHazardRecognizer for better cost estimation and scheduling. What is the reasoning for having scheduling information distributed in two distinct representations? Is it the lack of micro-architectural details or was it a design decision? Another question is if one could opt, which representation should me used...

...et that implements the > > scheduling as it will be? And does the bottom-up scheduling also account > > ARM is a good model. What part of ARM's implementation is associated with the bottom-up scheduling? I am confused because it looks like it is essentially using the same kind of ScoreboardHazardRecognizer that was commented out of the PPC 440 code. Thanks in advance, Hal > > > for pipeline-conflict hazards? > > Yes, definitely. And it should be doing a much better job of it. > > Evan > > > > > -Hal > > > > On Wed, 2011-10-19 at 16:45 -0700...

...es both results, it does not obey this hazard, and is issued the cycle immediately after. Are there any target hooks I need to implement to get this scheduling correctly? I noticed that my target was using the default HazardRecognizer, which is effectively disabled, so I changed it to use the ScoreboardHazardRecognizer instead. I'm also still using the SelectionDAG scheduler, but will need to change to the MI scheduler at some point, to keep up with trunk. Should either of these help? Thanks, Fraser -- Fraser Cormack Compiler Developer Codeplay Software Ltd 45 York Place, Edinburgh, EH1 3HP Tel: 0131...

Hi, Can someone tell me if my understanding is right in that post-RA scheduler currently assumes no limits on a pipeline's issue width? If so, is it by design or just overlooked? I have a case for, say, 1-issue pipeline when certain pipeline resource becomes occupied a few clocks after instruction start, but hazard evaluation is done incorrectly as scheduler advances clock not for every

...itineraries. This is > // required until SD and PostRA schedulers are replaced by MachineScheduler. > > This poses several question as to: > 1) which representation gives the better cost estimation? > 2) AFAIK, MachineScheduler can also take advantage from InstrItineraries with the ScoreboardHazardRecognizer for better cost estimation and scheduling. As the comment indicates, this was done for legacy reasons, to allow targets that already defined itineraries to migrate away from SelectionDAG scheduling, without defining a new machine model. What makes you think it was done "for better cost es...

Akira, Thanks you for response. I understand Post-RA schedule make uses of scoreboardHazardRecognizer. But I found mips codes are good enough by default. basically, I can not easily eyeball any bubbles. I don't understand how they can do that without post-RA-sched. pre-ra-scheduler eg. (SelectionDAG/ScheduleDAGRRList.cpp) has little information and they can only schedule node in topology or...

Hello. I see there is little information on specifying instructions with delay slots. So could you please tell me how can I insert NOPs (BEFORE or after an instruction) or how to make an aware instruction scheduler in order to avoid miscalculations due to the delay slot effect? More exactly, I have the following constraints on my (SIMD) processor: - certain stores or

...> scheduling as it will be? And does the bottom-up scheduling also account >> >> ARM is a good model. > > What part of ARM's implementation is associated with the bottom-up > scheduling? I am confused because it looks like it is essentially using > the same kind of ScoreboardHazardRecognizer that was commented out of > the PPC 440 code. > > Thanks in advance, > Hal Hi Hal, The best way to ensure the PPC scheduling isn't hosed now or in the future is probably to make it work as much like ARM as possible. This means (1) defaulting to the "hybrid" schedul...

...ry client). If you can do the same with PPC that's great. Andy On Nov 29, 2011, at 8:51 AM, Hal Finkel <hfinkel at anl.gov> wrote: >> Thanks! Since I have to change PPCHazardRecognizer for bottom-up support >> anyway, is there any reason not to have it derive from >> ScoreboardHazardRecognizer at this point? It looks like the custom >> bundling logic could be implemented on top of the scoreboard recognizer >> (that seems similar to what ARM's recognizer is doing). > > Also, how does the ARM hazard recognizer get away with not implementing > RecedeCycle? >...