similar to: [LLVMdev] MIScheduler / bundling

On Feb 1, 2013, at 3:43 PM, "Sergei Larin" <slarin at codeaurora.org> wrote: > I have a question about the following (four) asserts recently added in > bundleWithPred() and bundleWithSucc() (see below). What is the real danger > of reasserting a connection even if it already exist? The intention was to identify code that may have been converted from the old style a

Jakob, > The intention was to identify code that may have been converted from > the old style a little too quickly. I wanted to avoid bugs from a > global s/setIsInsideBundle/bundleWithPred/g search and replace. This is a good intent. Maybe a bit temporal but sound nevertheless. > finalizeBundle is calling 'MIBundleBuilder Bundle(MBB, FirstMI, > LastMI)' which ought to

Jakob, I have a question about the following (four) asserts recently added in bundleWithPred() and bundleWithSucc() (see below). What is the real danger of reasserting a connection even if it already exist? My problem with them happens when I try to call finalizeBundle() on an existing bundle to which I have added a new instruction. The goal - a new bundle header with liveness abbreviation, but

On Feb 4, 2013, at 8:59 AM, "Sergei Larin" <slarin at codeaurora.org> wrote: > Jakob, > >> The intention was to identify code that may have been converted from >> the old style a little too quickly. I wanted to avoid bugs from a >> global s/setIsInsideBundle/bundleWithPred/g search and replace. > > This is a good intent. Maybe a bit temporal but

Jakob, >... In this case you should either erase the old BUNDLE first, or unbundle it > from the instructions you are trying to finalize. This is exactly my point - I have to unbundle everything to re-bundle it back in :) ...but this case is trivial and I am OK with it. What is more unclear to me is this. How do you use Bundle.insert(I, MI->removeFromBundle()) Where MI == Bundle.End?

Jakob, Seems like an easy solution for this case... But let me ask you a more general question. The reason I kept on hanging on to the MBB->splice was (probably outdated) assumption that it will one day properly update liveness for instructions it moves... That is a serious matter for what I am trying to do (global code motion in presence of bundles). What is the current thinking? Will

Hi, Regarding the mischeduler, I wonder // For loops that are acyclic path limited, aggressively schedule for // latency. This can result in very long dependence chains scheduled in // sequence, so once every cycle (when CurrMOps == 0), switch to normal // heuristics. if (Rem.IsAcyclicLatencyLimited && !Zone->getCurrMOps() && tryLatency(TryCand, Cand, *Zone))

> > Of course, you want to duplicate as little of the generic scheduling logic > as you can. So I think the challenge is how to expose the > generic scheduler's functionality as a base class or composition of > utilities so that defining your strategy doesn't require too much > copy-paste. ​Isn't GCNMaxOccupancySchedStrategy [1] already an example on using

I am working on a project where we are integrating an existing pre-RA scheduler into LLVM and we are trying to match our peak register pressure values with the machine instruction schedulers values while using X86. I am finding some mismatches in test cases like the one attached. The registers "AH" and "AL" are live-out but not live-in and I don't see that they are defined

Hi, I have been experimenting for a while with tryCandidate() method of the pre-RA mischeduler. I have by chance found some parameters that give quite good results on benchmarks on SystemZ (on average 1% improvement, some improvements of several percent and very little regressions). Basically, I add a "latency heuristic boost" just above processor resources checking:

Hello, While tuning the MIScheduler for my target, I discovered a code that unnecessarily restricts the scheduler. I think this is a bug, but I would appreciate a second opinion. In file ScheduleDAGInstrs.cpp, the function MIsNeedChainEdge determines whether two MachineInstrs are ordered by a memory dependence. It first runs through the standard criteria (Do both instructions access memory?

On Feb 4, 2013, at 3:02 PM, "Sergei Larin" <slarin at codeaurora.org> wrote: > Jakob, > >> ... In this case you should either erase the old BUNDLE first, or unbundle > it >> from the instructions you are trying to finalize. > > This is exactly my point - I have to unbundle everything to re-bundle it > back in :) ...but this case is trivial and I am

Hi Quentin and llvm-dev, I've got a regalloc-related question that you might have an opinion or answer about. In our out-of-tree target we've been doing some bundling before register allocation for quite some time now, and last night a new problem popped up. What the fix should be depends on if this bundle is legal or not: BUNDLE %vreg39<imp-def,dead> *

> On Jun 28, 2017, at 5:10 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Oh wait, vreg1 is indeed used. > Yeah, having a dead flag here sounds wrong. I mean on the instruction itself. On the bundle, that’s debatable. That would fit the semantic “if no side effect you can kill it” (here there is side effect, we define other vregs). > >> On

On Feb 4, 2013, at 3:44 PM, "Sergei Larin" <slarin at codeaurora.org> wrote: > Seems like an easy solution for this case... But let me ask you a more > general question. > The reason I kept on hanging on to the MBB->splice was (probably outdated) > assumption that it will one day properly update liveness for instructions it > moves... That is a serious matter

Jakob, Consider a counterexample. In a late pass I speculatively move instructions between BBs to improve code density and handle some peculiar back end specific situations which could not be handled in earlier passes. I move instructions one at a time. Currently I do it in a worklist fashion - I collect several possible candidates, and then actually move one. Some moves are _speculative_. Next

On Jun 7, 2012, at 10:25 AM, "Sergei Larin" <slarin at codeaurora.org> wrote: > Generally as far as I concern, there is no way “generic” (platform independent) code can add instructions to bundles optimally I agree, there are too many ways of modeling stuff with bundles. That is why I took the philosophical stance of treating bundles as black boxes during RA. I think the

hello, I am using the following code >s<-"I am very happy, excited, and optimistic.I am very scared, annoyed, and irritated.Iraq?s political crisis entered its second week one step closer to the potential.dissolution of the government, with a call for elections by a vital coalition partner and a suicide attack that extended the spate of violence. that has followed the withdrawal.of

On Thu, Mar 29, 2012 at 03:51:10PM -0700, Andrew Trick wrote: > > On Mar 29, 2012, at 1:18 PM, Tom Stellard <thomas.stellard at amd.com> wrote: > > > On Thu, Mar 29, 2012 at 02:57:27PM -0500, Sergei Larin wrote: > >> Tom, > >> > >> I do not have your call stack, but packetizer calls > >> ScheduleDAGInstrs::buildSchedGraph to create

Hi, We have a new BE for a VLIW-like processor and I'm currently working on instruction bundles. Ideally, I'd like to have bundles *before* RA to model certain constraints, e.g. the exposed one by Tzu-Chien a while ago in his thread http://lists.cs.uiuc.edu/pipermail/llvmdev/2005-September/004798.html In order to build bundles, we have added a new bottom-up MIScheduler, right after