[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