search for: liverangeedit

...e bundle remat possible. I would like your input. Rematerialization has multiple steps: 1. Feasibility. RA knows the bundle defining a given SSA value of a virtual register. It calls TII.isTriviallyReMaterializable() to determine if the defining instruction can (and should) be rematerialized. See LiveRangeEdit::anyRematerializable(). 2. Feasibility at desired location. LiveRangeEdit::canRematerializeAt() then checks that the instruction can be rematerialized at the new location. This can fail if the instruction depends on virtual register values that are not available at the new location. 3. Remat. Liv...

...same flow as current remat is implemented. What we unterstood is RegAlloc<>.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...

...le remat possible. I would like your input. Rematerialization has multiple steps: 1. Feasibility. RA knows the bundle defining a given SSA value of a virtual register. It calls TII.isTriviallyReMaterializable() to determine if the defining instruction can (and should) be rematerialized. See LiveRangeEdit::anyRematerializable(). [Larin, Sergei] Obviously if you treat bundle as a black box this does not make much sense. or isTriviallyReMaterializable() should be able to parse bundle and produce compound answer. Problem is - you will not be able to find many opportunities like that. On the othe...

...e your input. > > Rematerialization has multiple steps: > > 1. Feasibility. RA knows the bundle defining a given SSA value of a > virtual register. It calls TII.isTriviallyReMaterializable() to > determine if the defining instruction can (and should) be > rematerialized. See LiveRangeEdit::anyRematerializable(). > > */[Larin, Sergei] Obviously if you treat bundle as a black box this > does not make much sense... or isTriviallyReMaterializable() should be > able to parse bundle and produce compound answer. Problem is -- you > will not be able to find many opportunit...

...re register allocation. 3 ) Output of the pass added in Step 2 will be a Map of def to instructions pointers (instructions which can be used to remat the given live range). The map will contain live ranges which is due to single instruction and multiple instructions. 4 ) The remat APIs defined in LiveRangeEdit.cpp will use analysis from the Map when a spill is required for RA. 5 ) The remat transformation APIs like rematerializeAt() will be teached to remat live ranges with multiple instructions too. 6 ) A cost analysis will be require to decide between remat and spill. This should be based on at least...

...t;> Rematerialization has multiple steps: >> >> 1. Feasibility. RA knows the bundle defining a given SSA value of a >> virtual register. It calls TII.isTriviallyReMaterializable() to >> determine if the defining instruction can (and should) be >> rematerialized. See LiveRangeEdit::anyRematerializable(). >> >> */[Larin, Sergei] Obviously if you treat bundle as a black box this >> does not make much sense… or isTriviallyReMaterializable() should be >> able to parse bundle and produce compound answer. Problem is – you >> will not be able to find m...

...> > Scary... Yeah, no kidding! >> So if Reg is an allocatable physical register, it gets returned as an >> implicit use. This directly contradicts the comment when talks about >> virtual registers exclusively. >> >> So who's right here? > > You want LiveRangeEdit::allUsesAvailableAt() which performs the same > check today. But not in 3.0, right? > The important point is that all registers read by the rematerialized > instruction have the same value at the new site. That applies to both > physical and virtual registers. Yes, absolutely. I act...

...and break down the current remat problems (spills but should remat, remat but should spill, should remat at a different location, etc) eg. for the llvm test suite, and show that your algorithms solves the most important ones. > > -Andy > >> >> 4 ) The remat APIs defined in LiveRangeEdit.cpp will use analysis from the Map >> when a spill is required for RA. >> >> 5 ) The remat transformation APIs like rematerializeAt() will be teached to remat >> live ranges with multiple instructions too. >> >> 6 ) A cost analysis will be require to decide bet...

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

...t should remat, remat but should >> spill, should remat at a different location, etc) eg. for the llvm test >> suite, and show that your algorithms solves the most important ones. >> >> >> >> >> -Andy >> >> >> 4 ) The remat APIs defined in LiveRangeEdit.cpp will use analysis from >> the Map >> when a spill is required for RA. >> >> 5 ) The remat transformation APIs like rematerializeAt() will be teached >> to remat >> live ranges with multiple instructions too. >> >> 6 ) A cost analysis will be requi...

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

On Nov 16, 2011, at 10:23 AM, David A. Greene wrote: > Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: >> You want LiveRangeEdit::allUsesAvailableAt() which performs the same >> check today. > > But not in 3.0, right? Yes, 3.0 defaults to RAGreedy which uses the new spilling framework. It is ignoring the -spiller=... command line option. Also note that SplitKit does cheap-as-a-copy rematerialization when split...

...llvm test suite, and show that your algorithms > > > > solves > > > > the most important ones. > > > > > > > > > > > -Andy > > > > > > > > > > > > > > > > 4 ) The remat APIs defined in LiveRangeEdit.cpp will use > > > > > > analysis > > > > > > from the Map > > > > > > > > > > > > > > > > > > > > > when a spill is required for RA. > > > > > > > > > > > >...

...as well. > #ifndef NDEBUG > break; > #endif Scary... > So if Reg is an allocatable physical register, it gets returned as an > implicit use. This directly contradicts the comment when talks about > virtual registers exclusively. > > So who's right here? You want LiveRangeEdit::allUsesAvailableAt() which performs the same check today. The important point is that all registers read by the rematerialized instruction have the same value at the new site. That applies to both physical and virtual registers. There is some ambiguity about instructions reading reserved registe...

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

...w do I get the range information for that value? I've tried looking at the MachineInstr at the def point, getting its defined register and looking at LiveIntervals to get an interval for the register, but that doesn't always return something sane. I'm in the middle of InlineSpiller so LiveRangeEdit is in play. Thanks for your help! -David

> I am not sure extending the scavenger is the right way to go about this. > > There are two different situations where we might need extra registers to > spill something: > > 1. When spilling a weird register class like predicate registers, we > already known during register allocation that we will need a scratch GPR > to assist with the spill. > > 2. When spilling

Is there a way to force or increase the likelihood of rematerialization of condition registers, instead of copying or spilling? mips isa doesn't have a handy instruction which enables reading or writing condition registers in one or two cycles (you need several shift and masking operations), so it makes more sense to rematerialize, if that's possible. On Sat, Apr 6, 2013 at 9:56 AM,

----- Original Message ----- > From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Akira Hatanaka" <ahatanak at gmail.com> > Sent: Saturday, April 6, 2013 11:56:28 AM > Subject: Re: [LLVMdev] [PATCH]

s/llvm-commits/llvmdev/ On Dec 9, 2011, at 12:58 PM, Arnold Schwaighofer wrote: > >> As Jakob pointed out to me, the core problem is that the current >> register scavenger implementation will only give you one register; for >> the PowerPC case, and it looks like for your case as well, we might >> really need two registers. In the short term, a reasonable solution