Re: altivec patches

[Aldy Hernandez <aldyh at redhat dot com>]

>>>>> "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