search for: inlinespil

...ly derive from the same def, in the sense that they can be traced through copies, phis, etc. back to a single instruction? I'm looking at scheduling the load in my example and I need to be able to check for conflicting stores within relevant live ranges. Is there a design document for the new InlineSpiller and SplitKit somewhere? -Dave

...print a weighted spill cost based upon the execution frequency of the basic block where the spill is inserted. My goal is to analyse what effect scheduling changes have on the sum of this weighted spill cost in some benchmarks. I've experimented doing this directly before a spill is inserted in InlineSpiller.cpp using MBFI.getBlockFreq() and LiveIntervals::getSpillWeight. My question is why are these functions sometimes indicating that the frequency of a block, or the weight of a spill is 0? A frequency of 0 doesn't make sense to me. Thanks, Austin Kerbow

...instruction? They are known the all come from the same value in the original live range from before live range splitting. The defining instruction may not exists any longer. It could have been rematerialized somewhere else. It could also have been PHI. > Is there a design document for the new InlineSpiller and SplitKit > somewhere? No. /jakob

...y, Sacramento ________________________________ From: qcolombet at apple.com <qcolombet at apple.com> on behalf of Quentin Colombet <qcolombet at apple.com> Sent: Wednesday, September 20, 2017 9:44:35 AM To: Kerbow, Austin Michael Cc: via llvm-dev Subject: Re: [llvm-dev] Spill Weight In InlineSpiller Hi Austin, > On Sep 19, 2017, at 11:29 PM, Kerbow, Austin Michael via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'm trying to compute and print a weighted spill cost based upon the execution frequency of the basic block where the spill is inserted. My goal is to analy...

...vide that might you? >> >> /Jonas >> >> From: Quentin Colombet [mailto:qcolombet at apple.com] >> Sent: den 2 december 2014 01:15 >> To: Jonas Paulsson >> Cc: llvmdev at cs.uiuc.edu; stoklund at 2pi.dk; Patrik Hägglund H >> Subject: Re: [LLVMdev] InlineSpiller.cpp bug? >> >> Hi Jonas, >> >> Thanks for your patience. >> >> I have looked into the problem you reported and although the fix you proposed seem correct, I am not sure yet this is the way to go. I would need the debug output of the regalloc to help you...

The InlineSpiller in 3.1 is quite different from the old spiller so I am trying to slog through the code and learn a bit. On a spill, the spiller calls traceSiblingValue. I gather that this is supposed to find the "original" def point of a value, checking back through copies, phis, etc. At the end we...

On Sep 19, 2012, at 10:13 AM, dag at cray.com wrote: > The InlineSpiller in 3.1 is quite different from the old spiller so I am > trying to slog through the code and learn a bit. > > On a spill, the spiller calls traceSiblingValue. I gather that this is > supposed to find the "original" def point of a value, checking back > through copies,...

On Sep 19, 2012, at 10:49 AM, <dag at cray.com> wrote: > Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > > So if there are multiple values between r2 and r3 (r2.1, r2.2, etc.) I > would just follow the chains implied by the SibValueInfo Deps array? > Basically, I want to find all of the live ranges related to r1. It really depends on what you're trying to do.

...to find a better solution. To apply such movements, I need to unassign a virtual register from a physical register and one from the memory, and swap those two. To unassign from a physical register, the method *unassign* from the *LiveRegMatrix* class can be used. But, in the other hand, the class *InlineSpiller* doesn't provide a similar method, like *unspill*. So I thought, instead of applying the spill directly during the first phase of the algorithm, I would store the virtual registers candidates to spill in an auxiliary structure. So that when it was decided to apply spill at some virtual regi...

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: >> If we decide to spill r3, we call traceSiblingValue to find the original >> def (the load). After traceSiblingValue we have the load instruction to >> define r1 and the value number information for r3. We don't have the >> value information from r2 as far as I can tell. >> >> Is that correct?

Hi, I have encountered a test case where InlineSpiller generates bad code. A register is reloaded but never spilled, and I suspect a bug in InlineSpiller. A register is live over a loop that also have two inner loops. It is not used or defined over the inner loops. It is split into two sibling registers, where one covers just the inner loops interv...

/// Optimizations after all the reg selections and spills are done. void InlineSpiller::postOptimization() { HSpiller.hoistAllSpills(); } Seems a problematic function to me, as hoistAllSpills() uses TII.storeRegToStackSlot() to insert new spills. The problem is, TII.storeRegToStackSlot is allowed to create new virtual registers, which can not be allocated a range as this whole t...

On Jul 15, 2012, at 9:20 AM, Borja Ferrer <borja.ferav at gmail.com> wrote: > Jakob, one more hint, I've placed some asserts around the code you added and noticed that the InlineSpiller::insertReload() function is not being called. > > 2012/7/14 Borja Ferrer <borja.ferav at gmail.com> > Hello Jakob, > > I'm still getting the error, I can give you any other debug info you need. I haven't pasted the regalloc debug info here because it is quite huge,...

When compiling trunk using gcc 4.1.2 on linux/ppc64, I now see a warning that I don't remember seeing previously: llvm[2]: Compiling InlineSpiller.cpp for Release+Asserts build /src/llvm-trunk-dev/include/llvm/ADT/PointerIntPair.h: In member function ‘const PointerTy* llvm::PointerIntPair<PointerTy, IntBits, IntType, PtrTraits>::getAddrOfPointer() const [with PointerTy = void*, unsigned int IntBits = 1u, IntType = bool, PtrTraits = l...

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: >> Ok, so in that case the traced-to VNInfo will have a def SlotIndex of >> Slot_Block or something? > > VNI->isPHIDef() Ah, that's what that means. Thanks a bunch for your help! -David

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: >> Are all of those sibling values guaranteed to ultimately derive from the >> same def, in the sense that they can be traced through copies, phis, >> etc. back to a single instruction? > > They are known the all come from the same value in the original live range from before live range splitting. Ok, that's

On Sep 20, 2012, at 10:59 AM, <dag at cray.com> wrote: > Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > >>> Are all of those sibling values guaranteed to ultimately derive from the >>> same def, in the sense that they can be traced through copies, phis, >>> etc. back to a single instruction? >> >> They are known the all come from

...he question is: is this sound and safe? It seems logical to me, but I would really appreciate some expert advice, Jonas From: Quentin Colombet [mailto:qcolombet at apple.com] Sent: den 18 november 2014 20:19 To: Jonas Paulsson Cc: llvmdev at cs.uiuc.edu; stoklund at 2pi.dk Subject: Re: [LLVMdev] InlineSpiller.cpp bug? Hi Jonas, Could you share your test case and/or file a PR? I'd like to see what is going on dynamically to help you. Thanks, -Quentin On Nov 18, 2014, at 3:26 AM, Jonas Paulsson <jonas.paulsson at ericsson.com<mailto:jonas.paulsson at ericsson.com>> wrote: Hi, I...

I think I'm getting a bit closer to the problem. I've found that the call to InlineSpiller::foldMemoryOperand() inside InlineSpiller::spillAroundUses() is causing the problems. As a test, I removed that call and with your yesterday's patch I'm not getting any errors at all, the code generated is the same one as with the call. This is happening when InlineSpiller::foldMemoryOpe...

...outer loop, has edge from BB#4 phi 10 } Is there anything else I can provide that might you? /Jonas From: Quentin Colombet [mailto:qcolombet at apple.com] Sent: den 2 december 2014 01:15 To: Jonas Paulsson Cc: llvmdev at cs.uiuc.edu; stoklund at 2pi.dk; Patrik Hägglund H Subject: Re: [LLVMdev] InlineSpiller.cpp bug? Hi Jonas, Thanks for your patience. I have looked into the problem you reported and although the fix you proposed seem correct, I am not sure yet this is the way to go. I would need the debug output of the regalloc to help you further, but here are my initial findings. traceSiblingV...