search for: hazardrecognizer

...ctions or by inserting NOOPs into the load delay slots: ---- For example, code which looks like that: load 0x1234, reg1 noop noop add reg1, 1 load 0x1236, reg2 can be safely transformed to: load 0x1234, reg1 load 0x1236, reg2 noop add reg1, 1 ---- It pleased us quite a lot when we found the HazardRecognizer-class. Without much effort we could assist LLVM to transform code like shown above (with simple (SDUse, delayCount)-map). Unfortunately we found now out that the HazardRecognizer is used only before register allocation, and the register allocator obviously may reschedule instructions, but doesn...

...e which looks like that: > > load 0x1234, reg1 > noop > noop > add reg1, 1 > load 0x1236, reg2 > > can be safely transformed to: > > load 0x1234, reg1 > load 0x1236, reg2 > noop > add reg1, 1 > > ---- > > It pleased us quite a lot when we found the HazardRecognizer-class. > Without much effort we could assist LLVM to transform code like shown > above (with simple (SDUse, delayCount)-map). > > Unfortunately we found now out that the HazardRecognizer is used only > before register allocation, and the register allocator obviously may > reschedu...

Dan: CellSPU could clearly benefit from the post-RA scheduler. In fact, we were thinking about writing a machine pass of our own. One thing that does "disturb" me is that both HazardRecognizer and post-RA sched assume there's only one kind of NOP. For Cell, there are two, depending upon the pipeline being filled. Pipe 0 takes "ENOP" whereas Pipe 1 take "LNOP" (depends on the low order PC bits.) -scooter On Jan 19, 2009, at 2:42 PM, Dan Gohman wrote: >...

On Jan 19, 2009, at 11:01 AM, Patrick Boettcher wrote: > > >>> And more generally: Is the hazardRecognizer the right and only way >>> to >>> solve our NOOP-minimizing problem? >> >> Perhaps you want to do this after register allocation is done. Dan is >> developing the post-allocation scheduler. You can try it out. > > Interesting. Can it already be found SVN?...

...0, reg1 add reg1, 4 Which won't work on our platform. It is missing 2 NOOPs after the last load. The DelaySlotFiller could add the two NOOPs, but that would be less optimal than doing the store-load before the add of reg2 and reg3 (no NOOP in that case). >> And more generally: Is the hazardRecognizer the right and only way to >> solve our NOOP-minimizing problem? > > Perhaps you want to do this after register allocation is done. Dan is > developing the post-allocation scheduler. You can try it out. Interesting. Can it already be found SVN? I will search the mail archive later,...

On Monday 19 January 2009 19:47, Dan Gohman wrote: > > Can they be used in conjunction with > > MemoryDependenceAnalysis? e.g. can we write a MachineInstructions- > > based > > memory dependence analysis that uses MachineMemoryOperands? > > Right, the existing MemoryDependenceAnalysis works in terms of > LLVM-IR-level Instructions, but yes, it would be possible

On Jan 19, 2009, at 3:38 PM, David Greene wrote: > On Monday 19 January 2009 16:42, Dan Gohman wrote: > >>>> Perhaps you want to do this after register allocation is done. >>>> Dan is >>>> developing the post-allocation scheduler. You can try it out. >>> >>> Interesting. Can it already be found SVN? I will search the mail >>>

On Monday 19 January 2009 16:42, Dan Gohman wrote: > >> Perhaps you want to do this after register allocation is done. Dan is > >> developing the post-allocation scheduler. You can try it out. > > > > Interesting. Can it already be found SVN? I will search the mail > > archive > > later, if not. > > Yes, it is in SVN. It's new, and so far

On Jan 19, 2009, at 5:06 PM, David Greene wrote: > On Monday 19 January 2009 18:21, Dan Gohman wrote: > >>> Dan, how does the scheduler handle memory dependence? I'm working >>> on >>> something that requires memory dependence information for >>> MachineInstructions. >> >> At the moment, it knows simple things, like constant pool loads

On Monday 19 January 2009 18:21, Dan Gohman wrote: > > Dan, how does the scheduler handle memory dependence? I'm working on > > something that requires memory dependence information for > > MachineInstructions. > > At the moment, it knows simple things, like constant pool loads > don't have dependencies, and references to distinct stack slots are >

...second is ready 2 cycles after issue. But when I issue an instruction that uses 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...

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

...t doesn't advance at the next available instruction - it always gets the same store. This might be because I did not specify in a file like [Target]Schedule.td the functional units, processor and instruction itineraries. Regarding the Stalls argument to my method [Target]DispatchGroupSBHazardRecognizer::getHazardType() I always get the argument Stalls = 0. This is no surprise since in PostRASchedulerList.cpp we have only one call to it, in method SchedulePostRATDList::ListScheduleTopDown(): ScheduleHazardRecognizer::HazardType HT = HazardRec->getHazardType(CurSUnit, 0/*no sta...

On Nov 29, 2011, at 10:47 AM, Hal Finkel wrote: > Andy, > > I should have been more clear, the ARM implementation has: > void ARMHazardRecognizer::RecedeCycle() { > llvm_unreachable("reverse ARM hazard checking unsupported"); > } > > How does that work? > > Thanks again, > Hal Hal, My first answer was off the top of my head, so missed the subtle issue. Just so you know, to answer questions like this I usua...

...n*** Scheduling [" << CurCycle << "]: "); You should see a two cycle difference between MyInstr and its second dependent. The scheduler won't insert nops for you. You'd need to do that in a target-specific way. > 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? The hazard recognizer won't help yo...

...ce between the two instructions. I enabled the post-RA scheduler, and noticed that it cared about the latencies, and started to rearrange the instructions accordingly. Is it necessary to use the post-RA scheduler to enforce such latencies? >> 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?...

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-RA (R...

...;m trying to do things as simply as possible in the initial prototype. Looking through the code it looks like only PPC architecture can return NoopHazard, and I'm not interested in PPC. If in addition I'm preventing avoidable stalls by different means, that means I can completely ignore the HazardRecognizer and CurCycle (for now)? Many thanks for any help, David Steven Tweed

Andy, I should have been more clear, the ARM implementation has: void ARMHazardRecognizer::RecedeCycle() { llvm_unreachable("reverse ARM hazard checking unsupported"); } How does that work? Thanks again, Hal On Tue, 2011-11-29 at 09:47 -0800, Andrew Trick wrote: > ARM can reuse all the default scoreboard hazard recognizer logic such as recede cycle (naturally since its...

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