search for: remated

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

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

Ok, this is 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

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:

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

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

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

...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 actions like LI splitting, the current representation works very well. In general, I want the RA to preserve bundles as well as to be able to model the constraint presented above in the thread. Should I fix the rematerialization code...

...ization. > > 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 > actions like LI splitting, the current representation works very well. > > In general, I want the RA to preserve bundles as well as to be able to > model the constraint presented above in th...

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

...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 > actions like LI splitting, the current representation works very well. > > In general, I want the RA to preserve bundles as well as to be able to > model the constraint presented above in the thread. > Should I fix t...

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

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)

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 leading to the bug. The bug is extremely subtle and nasty.

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