[llvm-bugs] [Bug 27609] New: We should have a LiveRegUnits utility class

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=27609

            Bug ID: 27609
           Summary: We should have a LiveRegUnits utility class
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: matze at braunis.de
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

This is not a bug but a possible code cleanup/slight performance improvement.
Just wanted to document my thoughts on it.

We currently use LivePhysRegs as a general purpose register liveness utility.
It is used after register allocation to start at the end of a basic block and
move upwards while maintaining the set of live registers.

LivePhysReg currently tracks live registers, while for most purposes it would
be enough to track liveness of the register units. In fact LivePhysRegs code
comes from a LiveRegUnits class but was changed to track registers in r197253
probably because that was needed by one of the first users
(StackMapLivenessAnalysis).
Looking at our code today I believe most users of LivePhysRegs should work as
well with LiveRegUnits while maintaining a set of register units should be
slightly more efficient than updating a set of live registers. There are also
out of tree targets with a gigantic number of tuple registers which would
certainly need a LiveRegUnits class if they ever need this functionality.

We should also look into the RegScavenger class. Part of what it does is what a
LiveRegUnits class would do, so that we could reuse the LiveRegUnits class in
the RegScavenger.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160502/a27365a5/attachment.html>