search for: recedecycl

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 usually need to...

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

...boardHazardRecognizer 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? > > Thanks again, > Hal

...ov 29, 2011, at 7:10 PM, Hal Finkel wrote: >> From the perspective of the hazard recognizer, from what I can tell, the > difference between the top-down and bottom-up modes are: > > In top-down mode, the scheduling proceeds in the forward direction. > AdvanceCycle() may be used, RecedeCycle() is not used. EmitInstruction() > implies a cycle-count increment. In bottom-up mode, scheduling proceeds > in the backwards direction (last instruction first). AdvanceCycle() is > not used, RecedeCycle() is always used to decrement the current cycle > offset (EmitInstruction() does *...

...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? Thanks again, Hal > > -Hal > > > > > > > See how this is done in the ScoreboardHazardRecognizer ctor: > > > MaxLookAhead = ScoreboardDepth; > > > > > > > > -Andy > > > > > -- Hal Finkel Postdoctoral Ap...

On Mon, 2011-11-28 at 15:45 -0800, Andrew Trick wrote: > > On Nov 28, 2011, at 3:35 PM, Hal Finkel wrote: > > > > > > > Is EmitInstruction used in bottom-up scheduling at all? The > > > version in > > > the ARM recognizer seems essential, but in all of the regression > > > tests > > > (and some other .ll files I have lying around),

...boardHazardRecognizer 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? > > Thanks again, > Hal _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

...r 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? >> >> Thanks again, >> Hal > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >

...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? > >> > >> Thanks again, > >> Hal > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >