similar to: Specify special cases of delay slots in the back end

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 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, 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 new to the schedulers implemented in the back end of LLVM. I am trying to handle data hazards in my simple processor, with instructions that execute in 1 cycle. I have tried the standard post-RA scheduler, implemented in lib/CodeGen/PostRASchedulerList.cpp, (with a ScoreboardHazardRecognizer), but I have some issues with some consecutive instructions that are

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

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

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

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

ARM 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

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

Hi Filip, > 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

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

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

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

> 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

Hi all, here is the current (unfinished) version of the VLIW support I mentioned. It is a patch over svn rev 141176. It includes the MachineInstrBundle class, and small required changes in a couple of outside LLVM files. Also includes a modification to Mips target to simulate a 2-wide VLIW MIPS. The scheduler is really silly, I did not want to implement a scheduler, just the bundle class, and

Hello. I come back to this thread. But I want to ask a slightly different question. Is there a way to have LLVM IR language intrinsics that are given at construction time a string that is written at assembly generation time as it is? (so, basically having placeholders of strings in LLVM that remain untouched until the end, including code generation time.) More exactly, I would

The Sparc, Microblaze, and Mips code generators implement branch delay slots. They all seem to exhibit the same bug, which is not surprising since the code is very similar. If I compile code with this snippit: while (n--) *s++ = (char) c; I get this (for the Microblaze): swi r19, r1, 0 add r3, r0, r0 cmp r3, r3, r7 beqid r3,