http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58621
Brian Grayson <b.grayson at samsung dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |---
--- Comment #2 from Brian Grayson <b.grayson at samsung dot com> ---
My understanding of the relocation for the ldr instruction is that the 'pimm'
field takes a number in the range 0 ... 16380, divides it by 4, and places it
in the 'imm12' field; thus, this case could be handled: the worst-case
situation is a symbol 4K-4 away from the section anchor, which could have an
offset of 4K-4, resulting in a total offset of 8K-8, and 8K-8 still fits within
the legal 0 ... 16K-4 range.
I verified the limits by changing the constant in the instruction to be 16380,
and assembling by hand; neither gcc nor ld choked, and the resulting
disassembly was:
400118: b97ffc40 ldr w0, [x2,#16380]
So for the ldr (64-bit), ldr (32-bit), and ldrh (16-bit) (and the sign-extend
variations thereof, and the equivalent store instructions), such an
optimization would be possible without concern for the page-crossing situation.
Accesses via ldrb would still need the pure computation of the full
section-anchor access to preserve correctness, but I highly suspect that the
dominant use of section anchors is not for byte-sized variables, and thus this
optimization would usually be feasible as long as the size was checked.
