similar to: [LLVMdev] Register pressure mechanism in PRE or Smarter rematerialization/split/spiller/coalescing ?

Hi, Daniel: Thanks a lot for detailed background information, we are willing to provide the right fix, however it will take time, do you mind if you forward me the discussion you had 5 months ago? I may not be able to access it since I only joined ellvmdev list this week. I did some performance measurement last night, some of our critical benchmark degraded up to 30% with your patch, so we have

> Given what you are saying, you are also suggesting we are not rematerializing addressing computations where it is cheaper to do so. That seems pretty critical to good RA :P Yep, about 5 months ago I had a conversation about this too... it may even be the one you're referencing. Our remat is really conservative - it only rematerializes values that have zero input operands (move immediate

That should be literally impossible, which makes me think something was tested wrong The second patch i posted disables scalar pre (assuming you use -disable-pre) but not load pre. Since the patch you reverted touched only scalar pre, disabling scalar pre should *also* do the same thing. On Thu, Jul 16, 2015 at 5:43 PM, Lawrence <lawrence at codeaurora.org> wrote: > Hi, Daniel: >

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

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 stack offset calculation. But marking some instruction

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

Spiller::Spill( LiveInterval *li, SmallVectorImpl<LiveInterval*> &newIntervals, const SmallVectorImpl<LiveInterval*> &spillIs ); has two reference vectors which contain a small list of Live Intervals. What is the register allocator's job to do with these intervals other than analysis. What more needed other than to know

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

Jeff Kunkel <jdkunk3 at gmail.com> writes: > Spiller::Spill( LiveInterval *li, >                           SmallVectorImpl<LiveInterval*> &newIntervals, >                           const SmallVectorImpl<LiveInterval*> &spillIs ); > > has two reference vectors which contain a small list of Live > Intervals. What is the register allocator's job to do

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

Daniel, My point is this, If (cond) ---- optimizer takes advantage of knowing cond == true within the “then” part Assert(cond) ---- optimizer takes advantage of knowing cond == true for the rest of the scope Assume(cond) ---- optimizer takes advantage of knowing cond == true for the rest of the scope If we aren’t implementing these in a consistent manner (like using an intrinsic for

On Fri, Jun 10, 2016 at 9:58 PM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > On Jun 10, 2016, at 7:00 PM, Lawrence, Peter via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Daniel, > My point is this, > > If (cond) ---- optimizer takes advantage of knowing cond == true within > the “then” part > Assert(cond)

Ok, thanks. Except the question was meant slightly different. Less w.r.t. organizing the register classes, and more w.r.t. implementation. I've noticed for instance that when trying to model this straight forwardly by writing a vreg from spills and reading this from fills (not further elaborated here), that the spiller can't handle vreg def-use pairs: there are assertions making sure a

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

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)

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 >

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

> 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

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

Daniel, Well then my next (dumb?) question is why aren’t we using source level assert information For optimization ? --Peter Lawrence. From: Daniel Berlin [mailto:dberlin at dberlin.org] Sent: Friday, June 10, 2016 5:39 PM To: Lawrence, Peter <c_plawre at qca.qualcomm.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Early CSE clobbering llvm.assume On Fri, Jun