search for: istriviallyrematerializ

...bundles without permission from the target. I think we need to tweak some of the TargetInstrInfo hooks to make 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 inst...

...without permission from the target. I think we need to tweak some of the TargetInstrInfo hooks to make 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(). [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...

...before*. > I think we need to tweak some of the TargetInstrInfo hooks to make > 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(). > > */[Larin, Sergei] Obviously if you treat bundle as a black box this > does not make much sense... or isTriviallyReMaterializable() should be > a...

...k we need to tweak some of the TargetInstrInfo hooks to make >> 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(). >> >> */[Larin, Sergei] Obviously if you treat bundle as a black box this >> does not make much sense… or isTriviallyReMaterializable() sh...

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