search for: regpressure

Hi All, The description of ScheduleDAGMILive [1] says: ScheduleDAGMILive is an implementation of ScheduleDAGInstrs that schedules machine instructions while updating LiveIntervals and tracking regpressure. Does the live interval and register pressure part of ScheduleDAGMILive mean the subclass of ScheduleDAGMILive is a pre-RA scheduler? I assume the post-RA scheduler no need to take care of live interval and register pressure, since RA is done already. Thanks. [1] http://llvm.org/doxygen/classll...

...here might I want to use these? Under what conditions might they improve an instruction schedule? Similar questions for the instruction scheduler strategies: -misched=(default, converge, ilpmax, ilpmin, or shuffle) And for the analysis heuristics: -misched-cluster, -misched-cyclicpath, -misched-regpressure, and -misched- fusion Are these things mutually exclusive or can they be combined? What combination will give the most rigorous analysis and improve scheduling (at the cost of longer runtime of llc) Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://li...

Hi, Indeed, the complex add is more expensive on all Cortex cores I know of. However there is an important point here that the code sequence we generate requires two registers live instead of one. In high regpressure loops, were probably losing performance. James On Wed, 11 Nov 2015 at 21:09, Tim Northover via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 11 November 2015 at 11:57, Meador Inge <meadori at gmail.com> wrote: > > Why wouldn't it consider the number of uses in any op...

...instead. To my surprise, this made the register allocator produce worse code in many cases. It seems that it is splitting live intervals and spilling more. In some cases the code was better. I wonder how this could be? Generally, using the immediates directly as constant operands should decrease regpressure, right? How could the RA-algorithm have been mislead by this? Thanks, Jonas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121022/297bbd16/attachment.html>

...not sure why LSR isn't handling it > later. > > For cases that LSR doesn't handle, we've been wanting an MI reassociate > pass in the backend anyway to expose ILP. That could clean up cases like this > when it's actually on the critical path and we don't mind the regpressure. > I inserted a small optimization pass to recognize and fix this exact sequence. This did indeed improve the performance (good ;) ), but not to the amount that I hoped.. I'll try to come up with a reduced file that shows this problem and file a bugreport for it. Greetings, Jeroen [...]

...s might they improve an instruction schedule? > > Similar questions for the instruction scheduler strategies: > > -misched=(default, converge, > ilpmax, ilpmin, or shuffle) > > And for the analysis heuristics: > > -misched-cluster, > -misched-cyclicpath, -misched-regpressure, and -misched- > fusion > > Are these things mutually exclusive or can they be combined? What combination will give the most rigorous analysis and improve scheduling (at the cost of longer runtime of llc) > > Phil > > _______________________________________________ > LLVM...

...k, that it is at least partially working]. > - New target description feature: buffered resources > - Modeling min latency, expected latency, and resources constraints Can you comment on how min and expected latency will be used in the scheduling? > - Heuristics that balance interlocks, regpressure, latency and > buffered resources > > For targets where scheduling is critical, I encourage developers who > stay in sync with trunk to write their own target-specific scheduler > based on the pieces that are already available. Hexagon developers > are doing this now. The LLVM to...

...gt; say DONE or WIP here, but your comment below implies, I think, that it > is at least partially working]. Glad you're interested. I can explain. We have several important tools in LLVM that most schedulers will need. That's what I was listing below (Configurable pass, DAG, LI update, RegPressure, Itinerary, HazardChecker--normally called a reservation table). I really should have also mentioned the DFAPacketizer developed by the Hexagon team. It's being used by their VLIW scheduler, but not by the new "standard" scheduler that I'm working on. Now that I mentioned that,...

...with sched=hybrid, the scheduler will fall back to register pressure scheduling unless the target implements TargetLowering::getSchedulingPreference. I forgot that piece of the puzzle. You could try simply returning Sched::ILP from PPCTargetLowering::getSchedulingPreference. If you have later have regpressure problems, you can so something more complicated like ARMTargetLowering::getSchedulingPreference. BTW - If you set HasReadyFilter, the fadd (105) would not even appear in the queue until the scheduler reached cycle [24]. So three additional stores would have been scheduled first. HasReadyFilter eff...

...t lists.llvm.org> wrote: >> >> Hi All, >> >> The description of ScheduleDAGMILive [1] says: >> >> ScheduleDAGMILive is an implementation of ScheduleDAGInstrs that >> schedules machine instructions >> while updating LiveIntervals and tracking regpressure. >> >> Does the live interval and register pressure part of ScheduleDAGMILive >> mean the subclass of ScheduleDAGMILive >> is a pre-RA scheduler? I assume the post-RA scheduler no need to take >> care of live interval and register pressure, >> since RA is done a...

...th filing a bug. I'm not sure why LSR isn't handling it later. For cases that LSR doesn't handle, we've been wanting an MI reassociate pass in the backend anyway to expose ILP. That could clean up cases like this when it's actually on the critical path and we don't mind the regpressure. -Andy > On 4/23/13 6:48 AM, Jeroen Dobbelaere wrote: >> Hi, >> >> I am investigating a performance degradation between llvm-3.1 and llvm-3.2 >> (Note: current top-of-tree shows a similar degradation) >> >> One issue I see is the following: >> - '...

We have run an experiment in which we set all physical register limits to zero. The purpose of this experiment was estimating the potential impact of getting complete liveness info. The results of this experiment were better than the results that we got using the real physical limits (the total number of spills in CPU2006 was reduced), but the difference was not substantial. We took this as an

...pendent precise modeling of register pressure: DONE - Register pressure reduction scheduler: WIP - Support for existing HazardChecker plugin - New target description feature: buffered resources - Modeling min latency, expected latency, and resources constraints - Heuristics that balance interlocks, regpressure, latency and buffered resources For targets where scheduling is critical, I encourage developers who stay in sync with trunk to write their own target-specific scheduler based on the pieces that are already available. Hexagon developers are doing this now. The LLVM toolkit for scheduling is all th...

...de the register allocator produce worse code in many > cases. It seems that it is splitting live intervals and spilling more. In > some cases the code was better. > > > > I wonder how this could be? Generally, using the immediates directly as > constant operands should decrease regpressure, right? How could the > RA-algorithm have been mislead by this? > > > > Thanks, > > > > Jonas > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http:/...

Hi, I was looking at some AArch64 benchmarks and noticed some simple cases where addresses are being folded into the address mode computations and was curious as to why. In particular, consider the following simple example: void f2(unsigned long *x, unsigned long c) { x[c] *= 2; } This generates: lsl x8, x1, #3 ldr x9, [x0, x8] lsl x9, x9, #1 str x9, [x0, x8] Given the two

On Tue, 2011-12-20 at 10:35 -0600, Hal Finkel wrote: > On Mon, 2011-12-19 at 23:20 -0800, Andrew Trick wrote: > > > > On Dec 19, 2011, at 10:53 PM, Hal Finkel wrote: > > > > > Here's my "thought experiment" (from PR11589): I have a bunch of > > > load-fadd-store chains to schedule. A store takes two cycles to > > > clear > >

...your comment below implies, I think, that > it > > is at least partially working]. > > Glad you're interested. I can explain. We have several important tools > in LLVM that most schedulers will need. That's what I was listing below > (Configurable pass, DAG, LI update, RegPressure, Itinerary, > HazardChecker--normally called a reservation table). > > I really should have also mentioned the DFAPacketizer developed by the > Hexagon team. It's being used by their VLIW scheduler, but not by the > new "standard" scheduler that I'm working on. &gt...

On Mon, 2011-12-19 at 23:20 -0800, Andrew Trick wrote: > > On Dec 19, 2011, at 10:53 PM, Hal Finkel wrote: > > > Here's my "thought experiment" (from PR11589): I have a bunch of > > load-fadd-store chains to schedule. A store takes two cycles to > > clear > > its last pipeline stage. The fadd takes longer to compute its result > > (say 5

...a bug. I'm not sure why LSR isn't handling it later. > > For cases that LSR doesn't handle, we've been wanting an MI reassociate pass in the backend anyway to expose ILP. That could clean up cases like this when it's actually on the critical path and we don't mind the regpressure. > > -Andy > > > On 4/23/13 6:48 AM, Jeroen Dobbelaere wrote: > >> Hi, > >> > >> I am investigating a performance degradation between llvm-3.1 and llvm-3.2 > >> (Note: current top-of-tree shows a similar degradation) > >> > >> One...

Andrew Trick <atrick at apple.com> writes: >> When I asked about enhancing scheduler heuristics a month or so ago, I >> got a response about a MachineInstr scheduler and that that was the way >> of the LLVM future. Is that so? Is the ScheduleDAG going away? > > You sent a lengthy RFC on Apr 20 that demonstrated you aren't > following developments on trunk.