search for: gethazardtype

...nce 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 stalls*/); L...

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 (Register Allocation) scheduler to avoid data hazards by inserting, if possible, other USEFUL instructions from the program instead of (just) NOPs. Is...

...e 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 have a data hazard in getHazardType() and return NoopHazard, the scheduler will not insert a NOP instruction in the respective place where I report the hazard . For me it is more convenient, in principle, to use the pre-RA scheduler, but it is not generating NOPs. Could you please tell me how can I generate NOPs with a pre-RA...

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 I have to insert a NOP in between by making getHazardTyp...

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

...; > entire hazard recognizer. > > 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), it is never called. It > seems that only Reset() and getHazardType() are called. Could you please > 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). Than...

...nkel 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), it is never called. It >> seems that only Reset() and getHazardType() are called. Could you please >> 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 > regre...

...om-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), it is never > > > called. It > > > seems that only Reset() and getHazardType() are called. Could you > > > please > > > 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 runni...

...isabling it instead of the > entire hazard recognizer. 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), it is never called. It seems that only Reset() and getHazardType() are called. Could you please explain the calling sequence? Thanks again, Hal > > Now, to generate the best PPC schedules, there is one thing you may > want to override. The scheduler's priority function has a > HasReadyFilter attribute (enum). It can be overriden by specializin...

...d, or give you a chance to reorder the instructions within a group once they've been selected. Ideally, you can express your constraints using InstrStage itinerary entries. If not, then you need to do your own bookkeeping by saving extra state during EmitInstruction and checking for hazards in getHazardType. At this point, you need to decide whether your custom logic can be easily generalized to either top-down or bottom-up scheduling. If not, you can force MISched to scheduling one either direction. SD scheduling is stuck with bottom-up for the remainder of its days, and postRA scheduling is top-down...

I'm considering writing more-detailed itineraries for some PowerPC CPUs that use the 'traditional' instruction grouping scheme. In essence, this means that multiple instructions will stall in some pipeline stage until a complete group is formed, then all will continue. I expect to provide CPU-specific code to help determine when the currently-waiting instructions would form a group.

...gt; > > > version in > > > > the ARM recognizer seems essential, but in all of the regression > > > > tests > > > > (and some other .ll files I have lying around), it is never > > > > called. It > > > > seems that only Reset() and getHazardType() are called. Could you > > > > please > > > > 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 > > > lea...

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. > > Thanks in advance, > Hal > > On Thu, 2011-10-20 at 10:21 -0700, Evan Cheng wrote: >> >> On Oct 19, 2011, at 7:29 PM, Hal Finkel <hfinkel at

Dear All, I am following a flow to generate object files(.o) from input (.s assembly) files. The input .s is given to AsmParser, which creates MCInst after matching instruction opcode. These MCInst are converted to MCStream and then finally emitting to an object file using Target Code Emitter. I am considering whether hazard recognition can be done on the list of MCInst, which I get after

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. Thanks in advance, Hal On Thu, 2011-10-20 at 10:21 -0700, Evan Cheng wrote: > > On Oct 19, 2011, at 7:29 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > Evan, > > > > Thanks for the heads up! Is

...nts on what those instructions can be, and which ones will move forward as the next dispatched group, and I think we need to fallback into C++ to deal with them. > If not, then you need to do your own bookkeeping by saving > extra state during EmitInstruction and checking for hazards in > getHazardType. At this point, you need to decide whether your custom > logic can be easily generalized to either top-down or bottom-up > scheduling. I think that it can be either. Within the current system, however, it might need to be top down. To do bottom up, you'd need to have look-ahead of the de...