[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
http://llvm.org/bugs/show_bug.cgi?id=21734
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