search for: ppchazardrecognizers

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

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

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

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

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

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

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

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

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

Andy, Is there any good info/docs on scheduling strategy in LLVM? As I was complaining to you at the LLVM meeting, I end up reverse engineering/double guessing more than I would like to... This thread shows that I am not exactly alone in this... Thanks. Sergei Larin -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. -----Original Message----- From: llvmdev-bounces 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 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 says...

Sergei, I would say that each target has its own scheduling strategy that has changed considerably over time. We try to maximize code reuse across targets, but it's not easy and done ad hoc. The result is confusing code that makes it difficult to understand the strategy for any particular target. The right thing to do is: 1) Make it as easy as possible to understand how scheduling works for

Andy, Thank you for the extended and prompt answer. Let me try to summaries my current position so you (and everyone interested) would have a better view of the world through my eyes ;) 1) LLVM first robust VLIW target is currently in review. It needs for scheduling strategy/quality are rather different than what current scheduler(schedulers) can provide. 2) My first attempt in porting