From mboxrd@z Thu Jan  1 00:00:00 1970
From: Aldy Hernandez <aldyh@redhat.com>
To: Dale Johannesen <dalej@apple.com>
Cc: gcc patches <gcc-patches@gcc.gnu.org>, Geoff Keating <geoffk@cygnus.com>
Subject: Re: altivec patches
Date: Tue, 13 Nov 2001 04:32:00 -0000
Message-ID: <m3zo60ljbs.fsf@litecycle.cc.andrews.edu>
References: <374D0C66-D239-11D5-AEDD-003065C86F94@apple.com>
X-SW-Source: 2001-11.fuckfuckfuck/msg00292.html
Message-ID: <20011113043200.jJyzoHO2HMDgLyyUtoVMFcus3k8QVgddawhvFgzwDoA@z>

>>>>> "Dale" == Dale Johannesen <dalej@apple.com> writes:

 > This is getting better.

Thanks ;-)

 > I'd really like to see vrsave in the enums and register macros
 > (not necessarily the code).  I dislike making a major change to
 > an area if we know it's going to change again shortly.

That was supposed to be tommorrow's work.... :)

 > If you plan to support linking files compiled with and without
 > -fabi=altivec,

nope we don't.  You can't just link too different abi's.

 >> +       /* Print AltiVec memory operand.  */
 >> +     case 'y':
 >> +       {
 >> + 	rtx tmp;
 >> +
 >> + 	if (GET_CODE (x) != MEM)
 >> + 	  abort ();
 >> +
 >> + 	tmp = XEXP (x, 0);
 >> +
 >> + 	if (GET_CODE (tmp) == REG)
 >> + 	  fprintf (file, "0, %s", reg_names[REGNO (tmp)]);
 >> + 	else if (GET_CODE (tmp) == PLUS && GET_CODE (XEXP (tmp, 1)) == REG)
 >> + 	  {
 >> + 	    if (REGNO (XEXP (tmp, 0)) == 0)
 >> + 	      fprintf (file, "%s,%s", reg_names[ REGNO (XEXP (tmp, 1)) ],
 >> + 		       reg_names[ REGNO (XEXP (tmp, 0)) ]);
 >> + 	    else
 >> + 	      fprintf (file, "%s,%s", reg_names[ REGNO (XEXP (tmp, 0)) ],
 >> + 		       reg_names[ REGNO (XEXP (tmp, 1)) ]);
 >> + 	  }
 >> + 	else
 >> + 	  abort ();
 >> + 	break;
 >> +       }

 > I guess this is OK.  Apple/Moto version doesn't have any analogous change
 > here; the patterns in rs6000.md match more elaborate MEM subpatterns,
 > to do the checking that you do here.  Isn't it generally considered
 > preferable
 > to use the existing pattern mechanism whenever possible?

What I do is have some legitimize_address hackery that will transform
incorrect memory addresses into something altivec memory addressing
can handle (mem (plus reg reg)), and then handle [reg+reg] and [reg]
as the %y print operand.

I dislike the idea of having lots of variants of memory addressing in
the MD file.  It seems cleaner to have just memory_operand() and then
have %operands print them out pretty :).

Aldy