search for: ppchazardrecognizer

...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. Andy, Thanks! Since I have to change PPCHazardRecognizer for bottom-up support anyway, is there any reason not to have it derive from ScoreboardHaz...

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; explain the calling sequence? > > 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 HT...

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

Heh, my ex-boss would die seeing something like this :-) Just one comment, does GCOV have a flag for a third category of lines, like "undesired to execute"? This would make the summary of <http://chandlerc.net/llvm-coverage/lib/Target/PowerPC/ PPCHazardRecognizers.cpp.gcov.html> much more favorable. Nice work! Cheers, Gabor

...RM can reuse all the default scoreboard hazard recognizer logic such as recede cycle (naturally since its the primary 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 recognize...

...as well insert NOPs in the [Target]AsmPrinter.cpp module . Thank you, Alex On 2/10/2017 1:42 AM, Hal Finkel wrote: > > On 02/09/2017 04:46 PM, Alex Susu via llvm-dev wrote: >> 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 st...

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

...in method SchedulePostRATDList::ListScheduleTopDown(): ScheduleHazardRecognizer::HazardType 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 h...

On Tue, 2011-11-22 at 13:27 -0600, Hal Finkel wrote: > On Tue, 2011-10-25 at 21:00 -0700, Andrew Trick wrote: > > On Oct 25, 2011, at 6:01 PM, Hal Finkel wrote: > > > Is there documentation somewhere for the bottom-up scheduling? I'm > > > trying to figure out what changes are necessary in order to support it > > > in the PPC backend. > > > >

Hello, I am trying to improve lib/Target/Mips/MipsDelaySlotFiller.cpp by substituting nops emitting with instructions reordering. I need a hazard recognizer, but I haven't found any. Do I have to create one, or looking bad and there is any? Thanks for any reply. -- Filip Kocina, student FIT Email: xkocin00 at stud.fit.vutbr.cz

...> I am trying to improve lib/Target/Mips/MipsDelaySlotFiller.cpp by > substituting nops emitting with instructions reordering. I need > a hazard recognizer, but I haven't found any. Do I have to create > one, or looking bad and there is any? You have to create one! Take a look at PPCHazardRecognizers.cpp and SPUHazardRecognizers.cpp for examples. If you can, contribute it back! :) -- Bruno Cardoso Lopes http://www.brunocardoso.cc

> You have to create one! Take a look at PPCHazardRecognizers.cpp > and SPUHazardRecognizers.cpp for examples. > If you can, contribute it back! :) There is also generic hazard recognizer which works on top of instruction itineraries. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

...ions. ;] Not always possible, but that is usually my ideal goal in testing. The key is to always check that the result of that execution is correct, so trigger assertions, and catch them, etc. > This would make the summary of > <http://chandlerc.net/llvm-coverage/lib/Target/PowerPC/ > PPCHazardRecognizers.cpp.gcov.html> > much more favorable. I'm not seeing the bad aspect of this particular file? It has pretty good coverage, is code calling into this "bad"? If so, then assertions, or logging or something might be more appropriate. Coverage just says that it got used, not that...

...coreboard hazard recognizer logic such as recede cycle (naturally since its the primary 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...

...RM can reuse all the default scoreboard hazard recognizer logic such as recede cycle (naturally since its the primary 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 recognize...

...izer logic such as recede cycle (naturally since its the primary 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 sim...

On May 26, 2008, at 11:55 PM, Chandler Carruth wrote: > This would make the summary of > <http://chandlerc.net/llvm-coverage/lib/Target/PowerPC/ > PPCHazardRecognizers.cpp.gcov.html> > much more favorable. > > I'm not seeing the bad aspect of this particular file? It has pretty > good coverage, is code calling into this "bad"? If so, then > assertions, or logging or something might be more appropriate. > Coverage just say...

...hazard recognizer logic such as > recede cycle (naturally since its the primary 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...

...; recede cycle (naturally since its the primary 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 > >>> (...