This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: An unusual x86_64 code model
On Thu, Aug 18, 2011 at 03:37:15PM +0200, Michael Matz wrote:
> On Wed, 17 Aug 2011, Jed Davis wrote:
>
> > One thing I'm not so sure about is accepting any SYMBOLIC_CONST as a
> > legitimate address. That allows, for example, a symbol address cast
> > to uintptr_t and added to (6ULL << 32), which will never fit. On the
> > other hand, -fPIC allows offsets of up to +/- 16Mib for some unexplained
> > reason,
>
> The x86-64 ABI specifies this. All symbols have to be located between 0x0
> and 2^31-2^24-1, and that is so that everything in memory objects of
> length less than 2^24 can be addressed directly.
Oh, of course. For some reason I went through the ELF spec, but
didn't think to see what the x86_64 ABI had to say about code models.
Everything makes much more sense now. Thanks for the pointer.
> Otherwise only the base address of symbols would be addressable
> directly and any offsetted variant would have to be calculated
> explicitely.
Right; that's what I was trying to avoid doing.
It looks like I can reuse legitimate_pic_address_disp_p for this; this
is not quite PIC, but the same set of non-immediate displacement-only
addresses is usable in general operands.
Except that then pic_32bit_operand does the wrong thing, because actual
PIC has hooks in the MI recog.c that affect the constraints (I think?),
and I don't. But... what "pic_32bit_operand" actually means is "can I
use LEA to obtain this value?", and anything that's a legitimate address
in strict RTL can be LEA'ed. So that takes care of that. Back to
testing, I guess.
--Jed