search for: remat

Hello Developers, I am working with my other batchmates to improve register remat in LLVM. We want to remat live ranges made of multiple instruction. Just to support our proposal here is a simple example that currently remat does not cover $ cat ~/tmp/tl.c void foo(long); void bar() { for (int i = 0; i < 1600; ++i) foo(3494348345984503943); } $ clang -O3 -S -o - ~/tm...

....org/citation.cfm?id=103136 <http://dl.acm.org/citation.cfm?id=103136>) as desribed in [1]. This pass will be scheduled to run before register allocation. >> >> 3 ) Output of the pass added in Step 2 will be a Map of def to instructions pointers (instructions which can be used to remat the given live range). The map will contain live ranges which is due to single instruction and multiple instructions. > > LiveIntervals maintains a quasi-SSA form via VNInfo. It does not allow efficient def-use queries, but use-def is there, which is all that you should need. I also only se...

On May 9, 2008, at 12:21 PM, David Greene wrote: > On Friday 09 May 2008 13:20, David Greene wrote: > >> One is that %reg1461 is assigned a register but LocalSpiller still >> tries to >> remat it instead of just using the register it was assigned to. I >> think >> it's easy enough to fix this problem, but I don't think this gets >> at the >> deeper issue. > > Duh. Of course this isn't a problem. We have to remat (or load) > this becau...

...a rather complicated e-mail. Please ask questions if you don't understand something. I've come across an interesting problem. I'm merging our graph coloring allocator with the code from trunk as of late last week. I have a code where a LiveInterval is spilled and some uses can be rematerialized. %reg1235 is spilled and at least one use is rematted. The remat def instruction is: %reg1235<def> = FsMOVLPDrm %reg1097, 1, %reg1364, 88, Mem:LD(8,8) [tmp17731774 + 0] So this gets entered into ReMatDefs. %reg1461 is created for one of the spill intervals of %reg1235. It i...

...<james at jamesmolloy.co.uk> wrote: > Hi, > > I've been looking at this myself for ARM, and came up with a much simpler > solution: lower immediate materializations to a post-RA pseudo and expand > the chain of materialization instructions after register allocation / > remat. Remat only sees one instruction with no dependencies. > > Did you look down this route and discount it? > No actually I am not much familiar with this topic so I mostly reply on research papers available. But your idea seems to be simple and good solution but I am not sure if this can cov...

...om> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Nirav Rana" > <h2015087 at pilani.bits-pilani.ac.in>, "Matthias Braun" > <matze at braunis.de> > Sent: Monday, September 19, 2016 1:27:10 PM > Subject: Re: [llvm-dev] [RFC] Register Rematerialization (remat) > Extension > Hi Vivek, > > On Sep 19, 2016, at 11:17 AM, vivek pandya via llvm-dev < > > llvm-dev at lists.llvm.org > wrote: > > > On Mon, Sep 19, 2016 at 6:21 PM, James Molloy < > > james at jamesmolloy.co.uk > wrote: > &gt...

On Friday 09 May 2008 13:20, David Greene wrote: > One is that %reg1461 is assigned a register but LocalSpiller still tries to > remat it instead of just using the register it was assigned to. I think > it's easy enough to fix this problem, but I don't think this gets at the > deeper issue. Duh. Of course this isn't a problem. We have to remat (or load) this because it's the result of spilling %reg1235....

On Friday 09 May 2008 14:49, Evan Cheng wrote: > > So the real problem is that one of the operands of the remat def was > > spilled. > > Perhaps if that happens we mark registers using that remat def as not > > rematable? > > We only allow instructions without any register operand and / or a > single pic base operand to be spilled. The later is a hack. :-) It's Do you mean &...

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

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

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

...truction is a load and whether an instruction writes to >> memory. > > Just use MI->mayLoad(), MI->mayStore(). Does this also account for arithmetic instructions with memops? These interfaces didn't exist in 2.9. > [And live interval analysis shouldn't be involved in remat these days.] Ok, I'm working off 2.9 so I'll have to update for trunk. That's no problem. >> The remat code itself identifies load instructions and checks to see >> whether it interferes with any instructions that write to memory. > > How does that affect compile ti...

Jakob I've just noticed that I'm getting false positives about spills when there are actually none. What is happening is that although execution reaches to the line spiller().spill(LRE); inside RAGreedy::selectOrSplit() the insertion of the spill is avoided because the register gets rematted. This is the debug output I'm getting to show what I mean: Inline spilling DLDREGS:%vreg25,1.436782e-03 = [344r,640r:0) 0 at 344r >From original %vreg8,1.838235e-03 = [224r,640r:0) 0 at 224r Value %vreg25:0 at 344r may remat from %vreg25<def> = LDIWRdK 2; DLDREGS:%vreg25 rema...

...;mayStore(). >> >> Does this also account for arithmetic instructions with memops? These >> interfaces didn't exist in 2.9. > > This is important because if mayLoad includes arithmetic instructions > with source memops (which I assume it will), it is unsuitable for remat > analysis. I don't think we want to remat general arithmetic quite yet. > At least that's not the intent of my change. I'll need some way to > identify "real" loads and I don't know of any other way other than > listing opcodes. Ideas? The target sets the...

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

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

...use MI->mayLoad(), MI->mayStore(). > > Does this also account for arithmetic instructions with memops? These > interfaces didn't exist in 2.9. This is important because if mayLoad includes arithmetic instructions with source memops (which I assume it will), it is unsuitable for remat analysis. I don't think we want to remat general arithmetic quite yet. At least that's not the intent of my change. I'll need some way to identify "real" loads and I don't know of any other way other than listing opcodes. Ideas? -Dave

...SimpleSpiller fails badly on a particular code. The problem arises because SimpleSpiller does the test VRM.isAssignedReg(virtReg) which is implemented as: 00183 bool isAssignedReg(unsigned virtReg) const { 00184 if (getStackSlot(virtReg) == NO_STACK_SLOT && 00185 getReMatId(virtReg) == NO_STACK_SLOT) 00186 return true; 00187 // Split register can be assigned a physical register as well as a 00188 // stack slot or remat id. 00189 return (Virt2SplitMap[virtReg] && Virt2PhysMap[virtReg] != NO_PHYS_REG); 00190 } VRM::assignVirt2Ph...

Ok, I've been tracking down a remat bug for over a week. I think I finally understand what is going on. This happens in specfp2006 leslie3d compiled with our frontend and optimizer. Unfortunately, getting a testcase is going to be impossible due to restrictions on SPEC redistribution and the complexity of the sequence of events le...

I'm working on some enhancements to rematerialization that I hope to contribute. It's mostly working but I am running into one problem. It boils down to having spilled a register used by the remat candidate. I thought this is what getReMatImplicitUse is supposed to handle but it looks inconsistent to me. The comment says this: ///...