This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: s390: SImode pointers vs LR


On 06/01/2015 06:23 AM, Andreas Krebbel wrote:
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))
	return false;

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
4Gb.

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:
https://gcc.gnu.org/ml/gcc-patches/2006-03/msg01495.html

I don't know if this is still necessary though.
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.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]