similar to: [LLVMdev] Does Mips resolve hazard in pre-ra-sched or post-ra-sched?

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

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

hi, LLVM, I found there is a flag DisableHazardRecognizer in TargetInstrImpl.cpp. I still don't understand how llvm detects data hazard in pre-RA-sched. pre-RA-sched is based on SDNode and all operands are vregs. Even you can calculate the operators of SDNodes, the data hazard in vreg are not same as physical register data hazard. Is it useful to optimize processor pipeline? thanks, --lx

On Sep 21, 2013, at 8:02 PM, Liu Xin <navy.xliu at gmail.com> wrote: > hi, LLVM, > > I found there is a flag DisableHazardRecognizer in TargetInstrImpl.cpp. I still don't understand how llvm detects data hazard in pre-RA-sched. pre-RA-sched is based on SDNode and all operands are vregs. Even you can calculate the operators of SDNodes, the data hazard in vreg are not same as

Hi, Andrew, Thank you for answering my question. What's the status of misched? is it experimental? I found it is disabled by default for all architectures(3.4svn). I also don't understand the algorithm. Could you point to me more papers or text materials about your approach? it seems that you want to balance register pressure and ILP in misched. On Tue, Sep 24, 2013 at 4:07 PM,

On Sep 25, 2013, at 11:03 PM, Liu Xin <navy.xliu at gmail.com> wrote: > > > > On Wed, Sep 25, 2013 at 1:15 PM, Andrew Trick <atrick at apple.com> wrote: > > On Sep 24, 2013, at 7:59 PM, Liu Xin <navy.xliu at gmail.com> wrote: > >> Hi, Andrew, >> >> Thank you for answering my question. >> >> What's the status of

On Sep 24, 2013, at 7:59 PM, Liu Xin <navy.xliu at gmail.com> wrote: > Hi, Andrew, > > Thank you for answering my question. > > What's the status of misched? is it experimental? I found it is disabled by default for all architectures(3.4svn). I also don't understand the algorithm. Could you point to me more papers or text materials about your approach? it seems

On Wed, Sep 25, 2013 at 1:15 PM, Andrew Trick <atrick at apple.com> wrote: > > On Sep 24, 2013, at 7:59 PM, Liu Xin <navy.xliu at gmail.com> wrote: > > Hi, Andrew, > > Thank you for answering my question. > > What's the status of misched? is it experimental? I found it is disabled > by default for all architectures(3.4svn). I also don't understand

> The underlying liveness datastructure is a list of ranges where each vreg is alive > (ranges in terms of instructions numbered). I remember a couple of later linear scan > papers describing the same thing (Traub et.al. being the first if I remember correctly). > That should be as accurate as you can get in terms of liveness information. It depends on the details. For example, given

The phi instruction is irrelevant; just the way I think about things. The question is if the allocator believes that t0 and t2 interfere. Perhaps the coalescing example was too simple. In the general case, we can't coalesce without a notion of interference. My worry is that looking at interference by ranges of instruction numbers leads to inaccuracies when a range is introduced by a copy.

How precise is the interference checking (to my mind, a great weakness of linear scan)? Is there way to do coalescing (the great strength of coloring)? I ask these questions because we (guys I work with) see loops where there's a little register juggling that seems unnecessary. Is there a paper that describes what y'all do? Thanks, Preston On Mon, Sep 10, 2018 at 9:57 AM, Matthias

I apologize if this has been asked before but which classes utilize the information in these files? I am asking since I am trying to extend the MIPS backend to 64bit among other things. Thanks in advance, Carter.

> On Sep 10, 2018, at 5:25 PM, Matthias Braun <mbraun at apple.com> wrote: > > > >> On Sep 10, 2018, at 5:11 PM, Preston Briggs <preston.briggs at gmail.com <mailto:preston.briggs at gmail.com>> wrote: >> >> The phi instruction is irrelevant; just the way I think about things. >> The question is if the allocator believes that t0 and t2

Yes. But it is not really being used by most (any?) targets because post-RA scheduling is disabled by default. Also, the existing model is very limited in what types of micro-architectures can be described. I've been extending it to enable scheduling of multi-issue targets, targets with overlapping FU usage, and targets that use and define registers in multiple pipeline stages. See

Hi, Using Chaitin's approach, removing a copy via coalescing could expose more opportunities for coalescing. So he would iteratively rebuild the interference graph and check for more opportunities. Chaitin was also careful to make sure that the source and destination of a copy didn't interfere unnecessarily (because of the copy alone); that is, his approach to interference was very

Actually after some digging I managed to answer these questions for myself. I am guessing that this information is used by the Schedule* classes in CodeGen. --- On Mon, 8/17/09, Carter Cheng <carter_cheng at yahoo.com> wrote: > From: Carter Cheng <carter_cheng at yahoo.com> > Subject: [LLVMdev] ARMSchedule.td MipsSchedule.td etc. > To: llvmdev at cs.uiuc.edu > Date:

Yes, I quite liked the things I've read about the PBQP allocator. Given what the hardware folks have to go through to get 1% improvements in scalar code, spending 20% (or whatever) compile time (under control of a flag) seems like nothing. And falling back on "average code" is a little disingenuous. People looking for performance don't care about average code; they care about

Any chance of adding some missing test coverage here? That code was dead (& evidently untested) before... On Thu, Jul 31, 2014 at 11:37 AM, Eric Christopher <echristo at gmail.com> wrote: > I believe you are correct. Fixed thusly: > > dzur:~/sources/llvm> git svn dcommit > Committing to https://llvm.org/svn/llvm-project/llvm/trunk ... > M