search for: rematerialization

I am a bit confused 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...

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

I'm working on an out-of-tree target and am having some problems with rematerialization 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...

...k boxes during RA. I think the target should be involved whenever bundles are formed, and we shouldn't delete instructions from inside bundles without permission from the target. I think we need to tweak some of the TargetInstrInfo 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 loc...

On Jun 3, 2013, at 6:05 AM, Steve Montgomery <stephen.montgomery3 at btinternet.com> wrote: > I'm working on an out-of-tree target and am having some problems with rematerialization 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...

...r, Inc. is a member of Code Aurora Forum. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Ivan Llopard Sent: Thursday, June 07, 2012 3:26 AM To: Jakob Stoklund Olesen Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] Instruction bundles before RA: Rematerialization Hi Jakob, 2012/6/6 Jakob Stoklund Olesen <stoklund at 2pi.dk> 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 bundl...

...t; schedule on the DAG. Bundles are built at exitRegion() in the scheduling > process and the live interval information is updated correctly. After > this, the RA is aware of bundles, at least from a LiveInterval point of > view, and I had some problems regarding the rematerialization. > > AFAIK, the RA cannot remat if the target instruction is not the bundle's > header. > For this, I rather need a light bundle representation, or no bundle at > all, so it can remat the right instruction with one condition: the > remated...

...comm Innovation Center, Inc. is a member of Code Aurora Forum. From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] Sent: Thursday, June 07, 2012 1:02 PM To: Sergei Larin Cc: 'Ivan Llopard'; 'LLVM Developers Mailing List' Subject: Re: [LLVMdev] Instruction bundles before RA: Rematerialization On Jun 7, 2012, at 10:25 AM, "Sergei Larin" <slarin at codeaurora.org> wrote: Generally as far as I concern, there is no way "generic" (platform independent) code can add instructions to bundles optimally I agree, there are too many ways of modeling stuff w...

...some tricky instructions, we cannot schedule on the DAG. Bundles are built at exitRegion() in the scheduling process and the live interval information is updated correctly. After this, the RA is aware of bundles, at least from a LiveInterval point of view, and I had some problems regarding the rematerialization. AFAIK, the RA cannot remat if the target instruction is not the bundle's header. For this, I rather need a light bundle representation, or no bundle at all, so it can remat the right instruction with one condition: the remated location should preserve bundles. Nevertheless, for many other...

Hi all, I'd like to force rematerialization by extending live intervals. For example: %vreg1 = opa %vreg2, %vreg3 ; 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 li...

...tions, we cannot > schedule on the DAG. Bundles are built at exitRegion() in the scheduling > process and the live interval information is updated correctly. After > this, the RA is aware of bundles, at least from a LiveInterval point of > view, and I had some problems regarding the rematerialization. > > AFAIK, the RA cannot remat if the target instruction is not the bundle's > header. > For this, I rather need a light bundle representation, or no bundle at > all, so it can remat the right instruction with one condition: the > remated location should preserve bundles....

...; > > > > -----Original Message----- > > From: Daniel Berlin [mailto:dberlin at dberlin.org] > > Sent: Wednesday, July 15, 2015 7:48 AM > > To: Lawrence > > Cc: LLVM Developers Mailing List > > Subject: Re: Register pressure mechanism in PRE or Smarter > rematerialization/split/spiller/coalescing ? > > > > On Tue, Jul 14, 2015 at 11:43 PM, Lawrence <lawrence at codeaurora.org> > wrote: > >> I thought about a little bit more, I think adding Register pressure > control in your patch or PRE may be the only choice. > >> > &gt...

...rum. >> >> *From:*Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] >> *Sent:* Thursday, June 07, 2012 1:02 PM >> *To:* Sergei Larin >> *Cc:* 'Ivan Llopard'; 'LLVM Developers Mailing List' >> *Subject:* Re: [LLVMdev] Instruction bundles before RA: Rematerialization >> >> On Jun 7, 2012, at 10:25 AM, "Sergei Larin" <slarin at codeaurora.org >> <mailto:slarin at codeaurora.org>> wrote: >> >> >> >> Generally as far as I concern, there is no way “generic” (platform >> independent) code can add...

...member of Code Aurora Forum. > > *From:*Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] > *Sent:* Thursday, June 07, 2012 1:02 PM > *To:* Sergei Larin > *Cc:* 'Ivan Llopard'; 'LLVM Developers Mailing List' > *Subject:* Re: [LLVMdev] Instruction bundles before RA: Rematerialization > > On Jun 7, 2012, at 10:25 AM, "Sergei Larin" <slarin at codeaurora.org > <mailto:slarin at codeaurora.org>> wrote: > > > > Generally as far as I concern, there is no way "generic" (platform > independent) code can add instructions to bund...

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

...Lawrence Hu > > > -----Original Message----- > From: Lawrence [mailto:lawrence at codeaurora.org] > Sent: Wednesday, July 15, 2015 9:36 PM > To: 'Daniel Berlin' > Cc: 'LLVM Developers Mailing List' > Subject: RE: Register pressure mechanism in PRE or Smarter rematerialization/split/spiller/coalescing ? > > Hi, Daniel: > > Thanks, I tried that patch you provided, it is better than just disabling your previous patch, it has more improvements than degradations. > > Do you want to post that patch or you want me to do that? > > Regards > > Lawre...

...will ask soon. http://reviews.llvm.org/D11234 Thanks again. Lawrence Hu -----Original Message----- From: Daniel Berlin [mailto:dberlin at dberlin.org] Sent: Wednesday, July 15, 2015 7:48 AM To: Lawrence Cc: LLVM Developers Mailing List Subject: Re: Register pressure mechanism in PRE or Smarter rematerialization/split/spiller/coalescing ? On Tue, Jul 14, 2015 at 11:43 PM, Lawrence <lawrence at codeaurora.org> wrote: > I thought about a little bit more, I think adding Register pressure control in your patch or PRE may be the only choice. > > Because at least for this case I am looking at, w...

...is purpose. Steve On 3 Jun 2013, at 17:30, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jun 3, 2013, at 6:05 AM, Steve Montgomery <stephen.montgomery3 at btinternet.com> wrote: > >> I'm working on an out-of-tree target and am having some problems with rematerialization 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 inst...

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