search for: rematable

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 - ~/tmp/tl.c -target

> On Sep 12, 2016, at 10:14 AM, Andrew Trick via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > >> On Sep 12, 2016, at 8:51 AM, vivek pandya via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> 1 ) As LLVM MI is already in SSA form before reg allocation so for LLVM I think it does not require to build

...roblem. We have to remat (or load) > this because > it's the result of spilling %reg1235. I got confused. :-/ > > 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 an ok hack because we know the pic base has a single definition and it's widely used throughout the function. So it doesn't really hurt to...

...ister needs to be marked unspillable or we can't remat %reg1235 or %reg1461 (since we don't know which operands of the def instruction might be spilled). Neither of these fixes seems doable. The first requires us to mark registers as unspillable without knowing whether the use marked as rematable will actually be spilled (%reg1461 in this case, which is marked rematable when it is created as a spill interval for %reg1235 but is in fact NOT spilled). The second requires us to severely limit rematerialization because we don't know which operands of a remat def instruction might be spil...

On Mon, Sep 19, 2016 at 6:21 PM, James Molloy <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

----- Original Message ----- > From: "Quentin Colombet via llvm-dev" <llvm-dev at lists.llvm.org> > To: "vivek pandya" <vivekvpandya at gmail.com> > 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:

.... Duh. Of course this isn't a problem. We have to remat (or load) this because it's the result of spilling %reg1235. I got confused. :-/ 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? -Dave

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 "remat" instead of "spill" here? If so, I think I know what the problem is. > I am not sure how you run...

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

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

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

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > That's great, but I really wish you would discuss the design of these > things publicly, and not develop features on long-running secret > branches. If you secretly start out in the wrong direction, you could > be wasting a lot of your time. I don't have a choice. I have to get patches approved after I already have

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

On Feb 27, 2012, at 9:51 AM, David A. Greene wrote: > dag at cray.com (David A. Greene) writes: > >>>> The change requires that live interval analysis be able to determine >>>> whether and instruction is a load and whether an instruction writes to >>>> memory. >>> >>> Just use MI->mayLoad(), MI->mayStore(). >> >>

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 >

...<>.cpp will try to allocate register to live-range, and if not possible, will call InlineSpiller.cpp to spill the live range. InlineSpiller.cpp will try to first rematerialize the register value if possible with help of LiveRangeEdit.cpp which provides various 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...

dag at cray.com (David A. Greene) writes: >>> The change requires that live interval analysis be able to determine >>> whether and instruction 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

I've been playing around with spillers and found that the 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)

...ead> ; srcLine 0 2820 %reg1198<def> = LEA64r %reg1591, 1, %reg1574, 0 ; srcLine 0 ##### %reg1591 gets spilled by linear scan with all of the uses in the sequence above reused by the "spltting" code in LiveIntervals. Note especially that %reg1591 is (correctly) identified at rematable (for the SUB64rr): ##### spilling(a): %reg1591,3.3557 = [2178,2802:4)[2802,2810:3)[2810,2818:2) [2818,2966:1)[2966,7840:0) 0 at 2966 1 at 2818-(2966) 2 at 2810-(2818) 3 at 2802-(2810) 4 at 2178-(2802) Set %reg2559 rematerialized with def: %reg1591<def> = MOV64ri64i32 32 ; srcLine 0 As...

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: /// getReMatImplicitUse - If the remat definition MI has