search for: rematerialize

...d how the rematerialization works. It seems currently in our backend we get lots of code where some stack offset address is calculated, but this address is then spilled to stack, and loaded from stack later. This does not make sense, it would be better to just recalculate the address later, ie rematerialize the original stack offset calculation. But marking some instruction rematerializable means all operands have to be always available? So I cannot make my add operation which is used for the stack offset calculations rematerializable because not all operands of all adds are always available? S...

Hello LLVM Developers, We are working on extending currently available register rematerialization to include cases where sequence of multiple instructions is required to rematerialize a value. We had a discussion on this in community mailing list and link is here: http://lists.llvm.org/pipermail/llvm-dev/2016-September/subject.html#104777 >From the above discussion and studying the code we believe that extension can be implemented in same flow as current remat is implemente...

...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 t...

...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 loca...

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

...he rematerialization code to look for the right > instruction into the current bundle ? > What's the direction you are following about instruction bundling ? Remat is a problem because it breaks the abstraction of treating whole bundles as instructions. There are two issues: - Should we rematerialize the full bundle defining a value, or should we try to dig out the 'real' def inside the bundle? The second option is the preferred one for us. The remated instruction should create a new bundle which may be merged with other bundles later by custom passes. The same condition applies for c...

...ode to look for the right > instruction into the current bundle ? > What's the direction you are following about instruction bundling ? Remat is a problem because it breaks the abstraction of treating whole bundles as instructions. There are two issues: - Should we rematerialize the full bundle defining a value, or should we try to dig out the 'real' def inside the bundle? The second option is the preferred one for us. The remated instruction should create a new bundle which may be merged with other bundles later by custom passes. The same condition applies...

...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 li...

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

...e rematerialization code to look for the right > instruction into the current bundle ? > What's the direction you are following about instruction bundling ? Remat is a problem because it breaks the abstraction of treating whole bundles as instructions. There are two issues: - Should we rematerialize the full bundle defining a value, or should we try to dig out the 'real' def inside the bundle? - After remat, we run dead code elimination in case the original def has no more uses. Again, should DCE erase a single instruction from inside a bundle, or should we erase the full bundle once...

...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 only, essentially). James On Wed, 15 Jul 2015 at 21:28 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 tur...

...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 n...

...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...

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

...g1954:hi16, %vreg1753 5056B %vreg1954:lo16<def> = mv_nimm6_ar16 0 5064B Store40FI %vreg1954, <fi#2> [...] 5128B %vreg223<def> = COPY %vreg1954 [...] 5216B %vreg1178<def> = COPY %vreg1954 [...] 5348B %vreg1955<def> = COPY %vreg1954 Then it tries to rematerialize: Value %vreg1954:0 at 5000r may remat from %vreg1954:hi16<def,read-undef> = mv_any16 32766 And it examines all use points of vreg1954 to see if it can remat or not: cannot remat for 5128e %vreg223<def> = COPY %vreg1954 cannot remat for 5216e %vreg1178<def> = COPY %vreg1954...

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