[LLVMbugs] [Bug 21734] New: [Statepoint] Remove explicit relocation of easily derived pointers

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Wed Dec 3 11:49:54 PST 2014


            Bug ID: 21734
           Summary: [Statepoint] Remove explicit relocation of easily
                    derived pointers
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: listmail at philipreames.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

For statepoints, we need to relocate any pointer (including derived pointers)
which are based on a garbage collector managed objects.  Currently, we do this
naively by explicitly recording every derived pointer for the GC to fix up.  We
can optimize this by only relocating the base pointer itself and re-indexing
off that base pointer to compute a derived pointer.

Given an input that looks like this:
%base = 
%ptr = gep %base + 15
statepoint ... %base, %ptr
%base' = gc.relocate(/*%base*/)
%ptr' = gc.relocate(/*%ptr*/)
%val = load %ptr'

We can convert it to:
%base = 
%ptr = gep %base + 15
statepoint ... %base, %ptr
%base' = gc.relocate(/*%base*/)
%ptr' = gep %base' + 15
%val = load %ptr'

There are a few benefits to this scheme:
- It reduces the required frame size since the derived pointer doesn't need to
be explicitly tracked.
- It avoids spill/reload costs for the derived pointer around safepoints.
- On architectures like x86 which support small offsets in their addressing,
avoiding the materialization of the derived address as a concrete register
value can be cheaper.
- If done early, it might assist the optimizer with alias queries involving
multiple accesses to the same object.  When each derived pointer is relocated
explicitly, the optimizer looses the information about how they're related.

There are a number of open questions which need resolved:
- What are the profitable cases of 'easily derived pointers'?  Small constant
offsets?  All constant offsets?  All geps?  
- Should this be done in CodeGenPrep or as an earlier IR transform?
- Does this need to be controlled by a target specific flag?

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/20141203/7d93f6a7/attachment.html>

More information about the llvm-bugs mailing list