similar to: [LLVMdev] Complicated Remat Question

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

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

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.

Dear Community, I would like to discuss few points to use RDF to extend register remat scope. Mr. Krzysztof and I have started discussion this on private mail. But I think now it would be better to include community. Interested community member kindly previous discussion (at the end of mail) before starting here. After analyzing if RDF can be used for solving Remat, we think that problem with

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

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

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

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

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

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 Feb 23, 2012, at 8:14 AM, David Greene <dag at cray.com> wrote: > I have a set of changes that enhances rematerialization to handle more > kinds of loads, specifically loads with multiple address registers. > This is a big win for some codes on x86. That's great, but I really wish you would discuss the design of these things publicly, and not develop features on

I have a set of changes that enhances rematerialization to handle more kinds of loads, specifically loads with multiple address registers. This is a big win for some codes on x86. I plan to send these up ASAP but I want to solicit a bit of guidance first. The change requires that live interval analysis be able to determine whether and instruction is a load and whether an instruction writes to

On Nov 16, 2011, at 9:15 AM, David Greene wrote: > I'm working on some enhancements to rematerialization that I hope to > contribute. What do you have in mind? > 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 >

On Wednesday 30 July 2008 16:03, David Greene wrote: > 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

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

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

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > On Nov 16, 2011, at 9:15 AM, David Greene wrote: > >> I'm working on some enhancements to rematerialization that I hope to >> contribute. > > What do you have in mind? Rematting more types of loads. >> /// getReMatImplicitUse - If the remat definition MI has one (for now, we only >> /// allow one)