This is the mail archive of the gcc-patches@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: [PATCH] Fix s390 fallout from PR11271 patch


> > However, this meant that R+R+CONST were not split as required
> > (on sparc) if this address was result of subreg adjustment.
> > In March 2003, Eric Botcazou committed a patch that replaced
> > the test for sp/fp/ap with a test for general base registers.
> > As far as I can see, this was intended to *widen* the range
> > of accepted registers, not restrict them.
> 
> Yes, this was the original intent.  In my own defense :-) I can say that I 
> was heavily influenced by the following comment, which is located a few 
> lines above the hot spot in reload.c:
> 
>   /* If we have address of a stack slot but it's not valid because the
>      displacement is too large, compute the sum in a register.
>      Handle all base registers here, not just fp/ap/sp, because on some
>      targets (namely SH) we can also get too large displacements from
>      big-endian corrections.  */
>   else if (GET_CODE (ad) == PLUS
> 	   && GET_CODE (XEXP (ad, 0)) == REG
> 	   && REGNO (XEXP (ad, 0)) < FIRST_PSEUDO_REGISTER
> 	   && REG_MODE_OK_FOR_BASE_P (XEXP (ad, 0), mode)
> 	   && GET_CODE (XEXP (ad, 1)) == CONST_INT)
> 
> So it appears that the "extension" process might be questionable there too.

If this code were to be enabled for the thumb case, I think we'd end up 
with invalid output.  The reason being that the code would attempt to 
generate a sum of the stack pointer and another register, but that's 
invalid: one of the reasons the stack pointer isn't classed as a base 
register is because this mode of addressing is not supported for stack 
accesses.

R.


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