[LLVMdev] Instruction bundles before RA: Rematerialization

[Jakob Stoklund Olesen]

On Jun 8, 2012, at 8:11 AM, Ivan Llopard <ivanllopard at gmail.com> wrote:

> Adding instructions into a bundle strongly depends on the target and may be a quite complex task, sometimes too complex to be done at allocation time if allocation speed is an issue.

Yes, we won't be adding instructions to bundles during RA. RA is already inserting copies and spill code as free-standing instructions between bundles. The target can add a post-RA bundling pass to mop up all that stuff if required.

>> [Larin, Sergei] At this point you need to update liveness on bundle level, and then update global picture. Updating liveness on bundle level also might need help from the back end. See the above example with .new, and you can easily imagine local defs/kills inside a bundle that should not even be visible outside the black box. As of now I consider this mechanism somewhat broken on trunk (it is overly pessimistic)… but API in this case is rather straightforward.
>> 
> I thought internals def/use were already modelled, is it right ?

Yes. MO.isInternalRead() models exactly that.

>> 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. 
>> 
> 
> IMHO, as long as internal defs/uses are taken into account, I don't see any particular problem.

It is easy to recognize that a virtual register has no uses outside the bundle, but we need help from the target to determine if that means some instructions are dead and can be deleted, and if so, which instructions to delete.

Target-independent code should never be deleting instructions from inside bundles without the target's say so.

It is not enough to check for internal uses. There could be other reasons to keep an instruction in a bundle.

/jakob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120608/f9729c05/attachment.html>