[PATCH] SubRegister liveness tracking

Matthias Braun mbraun at apple.com
Wed Oct 9 19:13:54 PDT 2013


You are right that patch was way more complicated that necessary. I rewrote most of it leaving a way simpler patch. Just needed a few invocation changes in the Coalescer patch.

Thanks
	Matthias

PS: I just created https://github.com/MatzeB/llvm-subreg-liveness which should make it easier to keep track of the current state of my patches...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0009-Add-subregister-aware-variants-of-LiveIntervalAnalys.patch
Type: application/octet-stream
Size: 5769 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131009/f1275eb7/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0011-Preserve-subregister-liveranges-in-register-coalesce.patch
Type: application/octet-stream
Size: 41768 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131009/f1275eb7/attachment-0001.obj>
-------------- next part --------------

On Oct 9, 2013, at 5:47 AM, Renato Golin <renato.golin at linaro.org> wrote:

> Hi Matthias,
> 
> Patch 0009, changes to pruneValue(), is a bit confusing.
> 
> If I got it right, the new void pruneValue() will call the old pruneValue (now returning a VNInfo), and iterate over the sub-ranges to prune them, too.
> 
> If that's right, then VNInfo *pruneValue() should be private, too, and void pruneValue2() could have a better name.
> 
> For my education, if I got it right, the pruneValue() family is removing the definition "Kill" from dead live ranges, after some optimizations killed some slots. Your change is extending this functionality to a "complicated case", which seems to allow deeper inspection of the control flow. I can see that you're doing a similar treatment over the successors of the current MBB.
> 
> Why is this complicated case not happening in LiveRanges, but only in SubRanges? Couldn't both be merged into one private implementation?
> 
> Also, I'd try to name the functions differently, possibly leaving "pruneValue" for the entry point (void) and having some more specialized names (like "pruneValueRange" and "pruneValueSubRange" for the private ones.
> 
> cheers,
> --renato



More information about the llvm-commits mailing list