search for: canrematerializeat

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

...eHeader)/ 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...

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

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