
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jun 7, 2012, at 10:25 AM, "Sergei Larin" <<a href="mailto:slarin@codeaurora.org">slarin@codeaurora.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span style="color: rgb(31, 73, 125); font-family: Calibri, sans-serif; font-size: 15px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); display: inline !important; float: none; ">Generally as far as I concern, there is no way “generic” (platform independent) code can add instructions to bundles optimally</span></blockquote></div><br><div>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 target should be involved whenever bundles are formed, and we shouldn't delete instructions from inside bundles without permission from the target.</div><div><br></div><div>I think we need to tweak some of the TargetInstrInfo hooks to make bundle remat possible. I would like your input.</div><div><br></div><div>Rematerialization has multiple steps:</div><div><br></div><div>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().</div><div><br></div><div>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.</div><div><br></div><div>3. Remat. LiveRangeEdit::rematerializeAt() calls TII.reMaterialize() (sic) to insert a copy of the defining instruction at the new location.</div><div><br></div><div>4. Shrink original live range. The original live range may be smaller after some uses have been rematerialized. This may discover dead defs if there are no remaining uses.</div><div><br></div><div>5. LiveRangeEdit::eliminateDeadDefs() erases the dead defs.</div><div><br></div><div>It looks like each of these steps require some help from the target if they are to handle bundles.</div><div><br></div><div>/jakob</div><div><br></div></body></html>