similar to: Pre-RA scheduler does not generate NOPs when getHazardType() returns NoopHazard

Hello. Hal, the problem I have is that it 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

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:

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

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

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),

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

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

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

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

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

Hi, Akira, I found you maintain mips MipsSchedule.td. does it correct? in MipsSchedule.td, every InstrItinData only uses one InstrStage. there's no ByPass info out there. are you sure this reflects the real R4xxx/R5xxx processors. why IILoad uses funcition unit ALU? InstrItinData<IILoad , [InstrStage<3, [ALU]>]> for my previous question, I have new input after

On Tue, 2011-11-29 at 08:29 -0600, Hal Finkel wrote: > 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

I have an instruction that takes no operands, and produces two results, in two consecutive cycles. I tried both of the following to my Schedule.td file: InstrItinData<IIMyInstr, [InstrStage<2, [FuncU]>], [1, 2]>, InstrItinData<IIMyInstr, [InstrStage<1, [FuncU]>, InstrStage<1, [FuncU]>], [1, 2]>, From what I can see in examples, these say that the first

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. > > > > Thanks in advance, > > Hal > > > > On Thu, 2011-10-20 at

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

On May 9, 2013, at 4:02 AM, Fraser Cormack <fraser at codeplay.com> wrote: > I have an instruction that takes no operands, and produces two results, in two consecutive cycles. > > I tried both of the following to my Schedule.td file: > > InstrItinData<IIMyInstr, [InstrStage<2, [FuncU]>], [1, 2]>, > InstrItinData<IIMyInstr, [InstrStage<1,

On 09/05/2013 18:25, Andrew Trick wrote: > > On May 9, 2013, at 4:02 AM, Fraser Cormack <fraser at codeplay.com > <mailto:fraser at codeplay.com>> wrote: > >> I have an instruction that takes no operands, and produces two >> results, in two consecutive cycles. >> >> I tried both of the following to my Schedule.td file: >> >>

Mips invokes the post-RA scheduler only when OptLevel > Aggressive, so you will have to compile with -O3. You can also invoke the MI (pre-RA) scheduler with llc option "-enable-misched". As you have pointed out, the post-isel scheduler is mandatory, and therefore you don't have to give any command line options. Currently, mips has only one generic scheduling itinerary model in

Hi, LLVM, I found LLVM codegen has 3 passes for instruction scheduling: 1) pre-ra sched 2) post-ra sched 3) mi sched. for RISC machines, there are data hazard cases appear only after Register Allocation(RA). for example, $t0 is used immediately after writing(RAW): ld $t0, MEM add $t2, $t0, $0 There may be one or more stall in pipeline. Instruction scheduler can detect this kinds of conflict

On Fri, Sep 20, 2013 at 3:30 AM, Liu Xin <navy.xliu at gmail.com> wrote: > Hi, Akira, > > I found you maintain mips MipsSchedule.td. does it correct? in > MipsSchedule.td, every InstrItinData only uses one InstrStage. there's no > ByPass info out there. > are you sure this reflects the real R4xxx/R5xxx processors. > > why IILoad uses funcition unit ALU? >