PowerPC64 non-delegitimized unspecs

I've noticed a number of tests fail on mainline with complaints about
non-delegitimized UNSPECs.  The reason why rs6000_delegitimze_address
isn't working is that our insn matching doesn't allow a stack slot in
place of the REG.  I could have expanded the condition to include
stack slots, but it seems silly to complicate the code like that.
Bootstrapped and regression tested powerpc64-linux.  OK for mainline
and 4.6?

	* config/rs6000/rs6000.c (rs6000_delegitimize_address): Relax
	UNSPEC_TOCREL matching.

On Wed, Apr 06, 2011 at 10:06:11PM +0930, Alan Modra wrote:
> I've noticed a number of tests fail on mainline with complaints about
> non-delegitimized UNSPECs.  The reason why rs6000_delegitimze_address
> isn't working is that our insn matching doesn't allow a stack slot in
> place of the REG.  I could have expanded the condition to include
> stack slots, but it seems silly to complicate the code like that.
> Bootstrapped and regression tested powerpc64-linux.  OK for mainline
> and 4.6?

Won't that lead to invalid debug info?
I mean, can't it happen that the reg in question is some register
initialized from TOC_REGISTER plus some offset?
Then the toc relative address wouldn't be the TOCREL operand, but
the TOCREL operand + (that register - TOC register).
That is something e.g. i386 or s390 handles...

For 4.6, complains about non-delegitimized UNSPECs shouldn't be seen,
as it is limited to --enable-checking, therefore if anything, I think
the changes should be done just for 4.7+.

> 	* config/rs6000/rs6000.c (rs6000_delegitimize_address): Relax
> 	UNSPEC_TOCREL matching.
> 
> Index: gcc/config/rs6000/rs6000.c
> ===================================================================
> --- gcc/config/rs6000/rs6000.c	(revision 171989)
> +++ gcc/config/rs6000/rs6000.c	(working copy)
> @@ -6367,18 +6367,7 @@ rs6000_delegitimize_address (rtx orig_x)
>      {
>        y = XEXP (XEXP (x, 1), 0);
>        if (GET_CODE (y) == UNSPEC
> -          && XINT (y, 1) == UNSPEC_TOCREL
> -	  && ((GET_CODE (XEXP (x, 0)) == REG
> -	       && (REGNO (XEXP (x, 0)) == TOC_REGISTER
> -		   || TARGET_MINIMAL_TOC
> -		   || TARGET_CMODEL != CMODEL_SMALL))
> -	      || (TARGET_CMODEL != CMODEL_SMALL
> -		  && GET_CODE (XEXP (x, 0)) == PLUS
> -		  && GET_CODE (XEXP (XEXP (x, 0), 0)) == REG
> -		  && REGNO (XEXP (XEXP (x, 0), 0)) == TOC_REGISTER
> -		  && GET_CODE (XEXP (XEXP (x, 0), 1)) == HIGH
> -		  && rtx_equal_p (XEXP (x, 1),
> -				  XEXP (XEXP (XEXP (x, 0), 1), 0)))))
> +          && XINT (y, 1) == UNSPEC_TOCREL)
>  	{
>  	  y = XVECEXP (y, 0, 0);
>  	  if (!MEM_P (orig_x))

	Jakub

On Wed, Apr 06, 2011 at 02:45:49PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 06, 2011 at 10:06:11PM +0930, Alan Modra wrote:
> > I've noticed a number of tests fail on mainline with complaints about
> > non-delegitimized UNSPECs.  The reason why rs6000_delegitimze_address
> > isn't working is that our insn matching doesn't allow a stack slot in
> > place of the REG.  I could have expanded the condition to include
> > stack slots, but it seems silly to complicate the code like that.
> > Bootstrapped and regression tested powerpc64-linux.  OK for mainline
> > and 4.6?
> 
> Won't that lead to invalid debug info?
> I mean, can't it happen that the reg in question is some register
> initialized from TOC_REGISTER plus some offset?

I don't think we do that on powerpc64.  Your question made me go back
to look at the failing tests, and I see that with current mainline the
tests no longer fail!  I guess for now I'd better retract the patch.