This is the mail archive of the
mailing list for the GCC project.
Re: s390: larl for Simode on 64-bit
- From: Jeff Law <law at redhat dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 08 Jul 2015 21:15:22 -0600
- Subject: Re: s390: larl for Simode on 64-bit
- Authentication-results: sourceware.org; auth=none
- References: <201507082033 dot t68KXrdI028695 at greed dot delorie dot com> <559D8DBD dot 60508 at redhat dot com> <201507082105 dot t68L57dx030059 at greed dot delorie dot com>
On 07/08/2015 03:05 PM, DJ Delorie wrote:
So in effect, we have two pointer sizes, 64 being the default, but we
can also get a 32 bit pointer via the syntax above? Wow, I'm surprised
In the TPF case, the software has to explicitly mark such pointers as
SImode (such things happen only when structures that contain addresses
can't change size, for backwards compatibility reasons):
int * __attribute__((mode(SImode))) ptr;
ptr = &some_var;
And the only time we'd be able to use larl is a dereference of a pointer
declared with the syntax above. Right
OK for the trunk with a simple testcase. I think you can just scan the
assembler output for the larl instruction.
Understood, but we also need to make sure that we don't do something
that breaks things. Thus I needed to know the tidbit about explicitly
declaring those pointers as SImode.
so I wouldn't consider this the "default" case for those apps, just
*a* case that needs to be handled "well enough", and the user is
already telling the compiler that they assume those addresses are
32-bit (that either the whole app, or at least the part with that
object, will be linked below 4Gb).
The majority of the addresses are handled as 64-bit.
 /me refrains from commenting on the worth of such practices, just
that they exist and need to be (and have been) supported.