search for: rematerialized

...e because not all operands of all adds are always available? So how can I make llvm to try to rematerialize only those stack offset adds, but not all adds? And also, when I have the stack update code in beginning and at end of the functions, these stack+immediate adds/subs also should not be rematerialized as the sp has changed?

...rious methods for checking if value is rematable or not. So we have added a new function in LiveRangeEdit that traverses sequence of instruction in use-def chain recursively (instead of only current instruction in consideration) upto depth 6 (arbitrarily taken for testing) to check if value can be rematerialized with the sequence of instruction or not. Here is the code: //New function added for checking complex multi-instruction-sequence rematerializable bool LiveRangeEdit::checkComplexRematerializable(VNInfo *VNI, const MachineInstr *DefMI,...

...and spilling. The target's load and store instructions affect the condition code register (CCR). Describing this in the InstrInfo.td file using Defs = [CCR] certainly prevents spills and fills from being inserted where they might clobber CCR but it also prevents the load instruction from being rematerialized because it defines a physical register (TargetInstrInfo::isReallyTriviallyReMaterializableGeneric()). I've tried to take the approach that's used by the X86 target, in which instructions _are_ trivially rematerializable even if they implicitly define the condition code (EFLAGS) but must ta...

...strInfo hooks to make bundle remat possible. I would like your input. Rematerialization has multiple steps: 1. Feasibility. RA knows the bundle defining a given SSA value of a virtual register. It calls TII.isTriviallyReMaterializable() to determine if the defining instruction can (and should) be rematerialized. See LiveRangeEdit::anyRematerializable(). 2. Feasibility at desired location. LiveRangeEdit::canRematerializeAt() then checks that the instruction can be rematerialized at the new location. This can fail if the instruction depends on virtual register values that are not available at the new locat...

...ng. > > The target's load and store instructions affect the condition code register (CCR). Describing this in the InstrInfo.td file using Defs = [CCR] certainly prevents spills and fills from being inserted where they might clobber CCR but it also prevents the load instruction from being rematerialized because it defines a physical register (TargetInstrInfo::isReallyTriviallyReMaterializableGeneric()). > > I've tried to take the approach that's used by the X86 target, in which instructions _are_ trivially rematerializable even if they implicitly define the condition code (EFLAGS) b...

I should probably voice our point of view as well… Hexagon is another VLIW target with “non standard” demands for bundling. I think Jacob has summarized current view of bundles as “black box” rather precise, but I should say that our view of bundles is way more fluid and open than that. To avoid going into lengthy discussion, let me just say – bundling for us is not a single occurrence, but

Hi Jakob, 2012/6/6 Jakob Stoklund Olesen <stoklund at 2pi.dk <mailto:stoklund at 2pi.dk>> On Jun 6, 2012, at 2:53 AM, Ivan Llopard <ivanllopard at gmail.com <mailto:ivanllopard at gmail.com>> wrote: > 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

...o hooks to make bundle remat possible. I would like your input. Rematerialization has multiple steps: 1. Feasibility. RA knows the bundle defining a given SSA value of a virtual register. It calls TII.isTriviallyReMaterializable() to determine if the defining instruction can (and should) be rematerialized. See LiveRangeEdit::anyRematerializable(). [Larin, Sergei] Obviously if you treat bundle as a black box this does not make much sense. or isTriviallyReMaterializable() should be able to parse bundle and produce compound answer. Problem is - you will not be able to find many opportunities lik...

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

...reg3 ; RClassA:%vreg1, RClassB:%vreg2, RClassB:%vreg3 ... somewhere between --> %vreg2<kill> and %vreg3<kill> .. %vreg4 = opb %vreg1 ; RClassA:%vreg1, RClassB:%vreg4 In my case, %vreg1 is not spillable and I'd like to extend vreg2 and vreg3 live intervals to get "opa" rematerialized. If I understand correctly, the InlineSpiller only rematerializes if all the operands values of "opa" reach "opb", right ? How can I extend the live interval of some VR even if it was already allocated ? Thanks in advance, Ivan

On Jun 6, 2012, at 2:53 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > 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 >

> Given what you are saying, you are also suggesting we are not rematerializing addressing computations where it is cheaper to do so. That seems pretty critical to good RA :P Yep, about 5 months ago I had a conversation about this too... it may even be the one you're referencing. Our remat is really conservative - it only rematerializes values that have zero input operands (move immediate

...r input. >> >> Rematerialization has multiple steps: >> >> 1. Feasibility. RA knows the bundle defining a given SSA value of a >> virtual register. It calls TII.isTriviallyReMaterializable() to >> determine if the defining instruction can (and should) be >> rematerialized. See LiveRangeEdit::anyRematerializable(). >> >> */[Larin, Sergei] Obviously if you treat bundle as a black box this >> does not make much sense… or isTriviallyReMaterializable() should be >> able to parse bundle and produce compound answer. Problem is – you >> will no...

...ossible. I would like your input. > > Rematerialization has multiple steps: > > 1. Feasibility. RA knows the bundle defining a given SSA value of a > virtual register. It calls TII.isTriviallyReMaterializable() to > determine if the defining instruction can (and should) be > rematerialized. See LiveRangeEdit::anyRematerializable(). > > */[Larin, Sergei] Obviously if you treat bundle as a black box this > does not make much sense... or isTriviallyReMaterializable() should be > able to parse bundle and produce compound answer. Problem is -- you > will not be able to f...

On Wed, Jul 15, 2015 at 1:10 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > IMHO, This doesn't make a lot of sense to turn off this part on it's own. > I would just use the enable-pre flag to turn off scalar PRE, as it > will cause the same issue in other cases as well. > Is there some reason you aren't just doing that? > I suspect if this is a performance

That should be literally impossible, which makes me think something was tested wrong The second patch i posted disables scalar pre (assuming you use -disable-pre) but not load pre. Since the patch you reverted touched only scalar pre, disabling scalar pre should *also* do the same thing. On Thu, Jul 16, 2015 at 5:43 PM, Lawrence <lawrence at codeaurora.org> wrote: > Hi, Daniel: >

Hi, Daniel: Thanks a lot for detailed background information, we are willing to provide the right fix, however it will take time, do you mind if you forward me the discussion you had 5 months ago? I may not be able to access it since I only joined ellvmdev list this week. I did some performance measurement last night, some of our critical benchmark degraded up to 30% with your patch, so we have

...> >> The target's load and store instructions affect the condition code register (CCR). Describing this in the InstrInfo.td file using Defs = [CCR] certainly prevents spills and fills from being inserted where they might clobber CCR but it also prevents the load instruction from being rematerialized because it defines a physical register (TargetInstrInfo::isReallyTriviallyReMaterializableGeneric()). >> >> I've tried to take the approach that's used by the X86 target, in which instructions _are_ trivially rematerializable even if they implicitly define the condition code (E...

Hi Quentin, On 08/19/14 18:58, Quentin Colombet wrote: [...] > It seems that you will have to debug further the *** Bad machine code: Instruction loads from dead spill slot *** before we can be of any help. Yes, I've done some more digging. Sorry for the long mail... I get: Inline spilling aN40_0_7:%vreg1954 [5000r,5056r:0)[5056r,5348r:1) 0 at 5000r 1 at 5056r At this point I have

On Jun 3, 2013, at 9:42 AM, Steve Montgomery <stephen.montgomery3 at btinternet.com> wrote: > I can use pseudo-instructions to bundle cmp+jump but it's not ideal because I might also have to bundle cmp+jump+jump+... into a pseudo. That may not be necessary. The register allocator won’t insert anything between terminators. /jakob