similar to: InlineSpiller - hoists leave virtual registers without live intervals

On Mon, Nov 4, 2019 at 12:18 PM Quentin Colombet <qcolombet at apple.com> wrote: > Hi Alex, > > Thanks for reporting this. > Wei worked on the hoisting optimization. > > @Wei, could you work with Alex to see what is the problem. > > Cheers, > -Quentin > > > On Nov 3, 2019, at 5:20 AM, via llvm-dev <llvm-dev at lists.llvm.org> > wrote: > >

On Sep 19, 2012, at 4:02 PM, dag at cray.com wrote: > Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > >> 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

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > 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

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, phis, etc. At the end we

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.

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?

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 have an interval being spilled and the original def instruction of the value. For

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

Hi Quentin, Thanks for the reply! However, we are not using any profiling-based compilation in our current work. We are assuming that, if PGO is disabled, the register allocator (and any other pass that needs basic block frequency info) will be basing its decisions on some kind of *static" basic block frequency info that are based on some compile-time heuristics and at least capture loop

Right Matthias, I am aware that an implementation for storeRegToStackSlot()/loadRegFromStackSlot() is necessary. But these functions receive the physical register that need to be spilled, they might receive the sub-register. In this case, using the super-register naively is unsafe (e.g., one might overwrite parts of it). Thus, I think the register allocator/spillar need to be aware of the

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

To make my point clear, I believe an implementation of storeRegToStackSlot()/loadRegFromStackSlot() is not sufficient (as it received the physical register already). Does this make sense? On 2018-01-30 13:33, ahmede wrote: > Right Matthias, I am aware that an implementation for > storeRegToStackSlot()/loadRegFromStackSlot() is necessary. But these > functions receive the physical

Hi, I'm implementing storeRegToStackSlot() and, in order to store some specific registers (floating point regs and address regs) I've to copy them to more standard regs and copy these last ones to the slot. I tried to generate instructions that use physical registers, but by doing that I overwrote registers already assigned by the register allocator. Is it possible to use virtual registers

Dan Gohman a écrit : > On Jan 23, 2009, at 3:28 AM, Mondada Gabriele wrote: > > >> Hi, >> I'm implementing storeRegToStackSlot() and, in order to store some >> specific registers (floating point regs and address regs) I've to >> copy them to more standard regs and copy these last ones to the slot. >> I tried to generate instructions that use

## Problem description One of the responsibilities of a target's implementation of TargetFrameLowering::emitPrologue is to set the frame pointer (if needed). Typically, the frame pointer will be stored to the stack just like the other callee-saved registers, and emitPrologue must insert the instruction to change its value after it was stored to the stack. Mips does this by looking at the

Hi Jakob, I believe Hal is trying to enable register scavenger to find two (or more) registers that can be used as temporaries. One problem I see with this approach is that, if you use register scavenger during PEI, you will have to pessimistically set aside two emergency spill slots before you call scavengeRegister, even if it turns out you only need one. Having an extra stack slot might not be

On Jan 23, 2009, at 3:28 AM, Mondada Gabriele wrote: > Hi, > I'm implementing storeRegToStackSlot() and, in order to store some > specific registers (floating point regs and address regs) I've to > copy them to more standard regs and copy these last ones to the slot. > I tried to generate instructions that use physical registers, but by > doing that I overwrote

In our case, storeRegToStackSlot, loadRegFromStackSlot clobbers some other physical register which may be holding a live value used somewhere else. How do I make regalloc aware so that it saves the value before storeRegToStackSlot and make it available again at the point of earlier use? TIA, Sanjiv -------------- next part -------------- An HTML attachment was scrubbed... URL: