https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85752
Bug ID: 85752
Summary: RFE: self-relative (prepickled) pointers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
If a pointer is optionally stored as a self-relative value rather than
absolute, it would enable the following use cases containing arbitrarily
complex data structures without needing any special "pickling":
- Shared memory segments
- Persistent memory
- Shared libraries (without expensive fixups)
An type attribute (or similar) would have to be attached to the pointer; a
pointer to such a pointer would be incompatible with a non-relative pointer.
These use cases have in common that they involve memory areas that have to work
correctly when mapped at different virtual addresses.
This could also, optionally, allow for 4-byte pointers on 64-bit architectures,
although this could definitely cause strange bugs if such a pointer was
writable and was written with a pointer outside the memory area -- but in the
cases listed above, such a pointer would be invalid anyway.
The cost of referencing such a pointer should be fairly minimal. On
architectures which support base+index addressing, such as x86, the overhead
might even be zero in many cases, as a sequence like:
# *rsi += rax;
movq (%rsi),%rdx # Load pointer
addq (%rdx),%rax
... can be transformed into ...
movq (%rsi),%rdx # Load relative pointer
addq (%rsi,%rdx),%rax
Of course, expressions that are indexed relative to the loaded pointers would
require an additional add/lea instruction.
With 4-byte relative pointers, the sequence would use movslq instead of movq:
movslq (%rsi),%rdx # Load and sign extend relative pointer
addq (%rsi,%rdx),%rax
Storing pointer values to memory would typically require an extra subtract
operation, of course.
I am filing this under "other" as I'm not sure where it needs to go. At least
in C++ I it can actually be done without compiler changes by doing casting
between pointers and ptrdiff_t and wrapping it in a template, but I'm not sure
if that would wreck alias analysis.
