search for: rematerializeat

...s 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 two factors register pressure and spill cost Few points: -------------- * The analysis pass to be addes as per (2) will us...

...vm 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 between remat and spill. This should be based on at least two factors register pressure and spill cost >> >> Few points: >> -----------...

...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. LiveRangeEdit::rematerializeAt() calls TII.reMaterialize() (sic) to insert a copy of the defining...

...ms 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 between remat and spill. >> This should be based on at least two factors register pressure and spill >> cost >> >> Few poi...

...ader)/ MoveMIAfterBundle(MI, BundleHeader). Calling this repeatedly should achieve desired effect - remove what could be removed, and live what needs to remain bundled intact. The move utility can change instruction properly for each target. 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. [Larin, Sergei] This looks similar to the previous case. Good thing that you can potentially have zero co...

...he 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. > > > > > &g...

...rnal read and the RA should consult the target before. Anyway, I think we both agree that instruction removal is a target-specific task. It also remains simple compared to the insertion of instructions into a bundle. > *//* > > 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. > > */[Larin, Sergei] This looks similar to the previous case. Good thing > that...

...39;m wrong: as long as the second operand of 'cmp' has not been allocated (and if it's available of course), it can be remated. Otherwise, it's tied to the bundle. Is that correct? > >> *//* >> >> 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. >> >> */[Larin, Sergei] This looks similar to the previous case. Good...

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

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