similar to: A use of RDF to extend register 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 - ~/tmp/tl.c -target

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, I commited several patches today that implement a framework that enables data-flow optimizations on the post-RA (post-SSA) representation. I thought I'd say a few words about what it is. The code is currently under lib/Target/Hexagon, but there intent for it from the beginning was to be target-independent. The motivation for it came from our (Hexagon) experience with customer

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

----- 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 Jun 7, 2012, at 10:25 AM, "Sergei Larin" <slarin at codeaurora.org> wrote: > Generally as far as I concern, there is no way “generic” (platform independent) code can add instructions to bundles optimally I agree, there are too many ways of modeling stuff with bundles. That is why I took the philosophical stance of treating bundles as black boxes during RA. I think the

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

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 >

On 3/1/2016 11:26 AM, vivek pandya via llvm-dev wrote: > > Still I am looking for feedback on RDF part and also if some one is > willing to mentor me. Hi Vivek, Sorry, I missed this email. I wrote the RDF stuff and I'd be happy to help you out with it if you are interested. The idea was to have a utility class that would represent the data flow between registers. The registers

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 Sergei, Jakob, Thanks for your comments ! On 07/06/2012 20:41, Sergei Larin wrote: > > Jakob, > > Please see my comments below. Hope this helps. > > Sergei > > -- > > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. > > *From:*Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] > *Sent:* Thursday, June 07, 2012 1:02 PM > *To:* Sergei

Jakob, Please see my comments below. Hope this helps. Sergei -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] Sent: Thursday, June 07, 2012 1:02 PM To: Sergei Larin Cc: 'Ivan Llopard'; 'LLVM Developers Mailing List' Subject: Re: [LLVMdev] Instruction bundles before RA: Rematerialization

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

Hi again! On 08/06/2012 17:11, Ivan Llopard wrote: > Hi Sergei, Jakob, > > Thanks for your comments ! > > On 07/06/2012 20:41, Sergei Larin wrote: >> >> Jakob, >> >> Please see my comments below. Hope this helps. >> >> Sergei >> >> -- >> >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. >>

Hi Venu, FWIW, I have a pass that does copy propagation after RA [1] (currently only within a basic block) that should be enabled some time in the not-too-distant future. It has been reviewed and accepted, but I'm currently working on getting a slight change to the MachineOperand representation [2] that should make the copy propagation change much simpler. I believe this change to

I should probably voice our point of view as well… Hexagon is another VLIW target with “non standard” demands for bundling. I think Jacob has summarized current view of bundles as “black box” rather precise, but I should say that our view of bundles is way more fluid and open than that. To avoid going into lengthy discussion, let me just say – bundling for us is not a single occurrence, but

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

On Tue, 17 Apr 2007, David Greene wrote: > Evan Cheng wrote: >> Obviously, smart heuristics can make a big difference here (estimated >> register pressures, etc.) But the more important thing is how the >> passes down stream can recover from the earlier mistakes. By this, we >> mean live range splitting and re-materialization. > > Can you explain this a little

Hi Geoff/Krzyssztof, Wouldn't the isRenamable() change be required even for the RDF based copy propagation? Maybe Hexagon does not impose ABI/ISA restrictions which require specific registers to be used in specific contexts. Also, if Geoff's copy propagation pass is invoked post-RA wouldn't it need to handle the x86 ISA feature which allows 8 bit/16 bit values to be moved into a