This is the mail archive of the
mailing list for the GCC project.
Re: s390: SImode pointers vs LR
- From: Jeff Law <law at redhat dot com>
- To: Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>, DJ Delorie <dj at redhat dot com>, gcc at gcc dot gnu dot org
- Date: Mon, 01 Jun 2015 09:06:56 -0600
- Subject: Re: s390: SImode pointers vs LR
- Authentication-results: sourceware.org; auth=none
- References: <201505300057 dot t4U0vj16030907 at greed dot delorie dot com> <556C4EB9 dot 3080906 at linux dot vnet dot ibm dot com>
On 06/01/2015 06:23 AM, Andreas Krebbel wrote:
Looks like a hack to me. Sadly, no testcase in that BZ, though
presumably since it was a bootstrap failure one could checkout a
development tree from that era and see the failure.
On 05/30/2015 02:57 AM, DJ Delorie wrote:
In config/s390/s390.c we accept addresses that are SImode:
if (!REG_P (base)
|| (GET_MODE (base) != SImode
&& GET_MODE (base) != Pmode))
However, there doesn't seem to be anything in the s390's opcodes that
masks the top half of address registers in 64-bit mode, the SImode
convention seems to just be a convention for addresses in the first
So... what happens if gcc uses a subreg to load the lower half of a
register (via LR), leaving the upper half with random bits in it, then
uses that register as an address? I could see no code that checked
for this, and I have a fairly large and ungainly test case that says
it breaks :-(
My local solution was to just disallow "SImode" as an address in
s390_decompose_address, which forces gcc to do an explicit SI->DI
conversion to clear the upper bits, and it seems to work, but I wonder
if it's the ideal solution...
We also have address style operands which are used as shift count operands but never as addresses.
Accepting SImode there was necessary to prevent reload from messing things up:
I don't know if this is still necessary though.