Re: altivec patches

[Geoff Keating <geoffk at geoffk dot org>]

> Cc: gcc-patches@gcc.gnu.org
> From: Aldy Hernandez <aldyh@redhat.com>
> Date: 05 Nov 2001 22:29:51 -0500

>  > The DWARF_FRAME_REGISTERS change seems to have gone away, which is not
>  > quite right:  it has to happen _only when the ABI is 'altivec'_.
> 
> I took it out because it needs rethinking.  DWARF_FRAME_REGISTERS is
> used as an array size in a few places, particulary unwind-dw2.c.  So I
> need to change all these places to dynamically allocate their space.

Before changing anything in the unwinder code, you must first make
sure that you're not changing an ABI.  I don't know what the new rules
are on this, with shared libgcc and all, so I will leave you to figure
them out (and please tell me when you do!).  You'll probably want to
ask on the glibc lists.

>  > This will be a bit tricky because DWARF_FRAME_REGISTERS is also used
>  > in libgcc, so you have to #define something when the Altivec ABI is
>  > chosen, and then key off that if IN_LIBGCC2.
> 
>  > I wonder if you could assume that the integrated cpplib will always be
>  > used when compiling libgcc?  That would make things easier, because
>  > then you wouldn't have muck with specs so much.
> 
> Please explain.  I only see DWARF_FRAME_REGISTERS being used in
> dwarf2out.c and unwind-dw2.c.  There is nothing in libgcc*.

unwind-dw2.c is part of libgcc, see LIB2ADDEH in Makefile.in.  I don't
knew about the new arrangement, but it used to be that 'struct
_Unwind_Context' (or equivalent) was passed between a bit of libgcc
that was compiled into glibc, and another bit of libgcc that was
compiled into applications.  Thus, you couldn't change
DWARF_FRAME_REGISTERS because that would change a glibc ABI.

For EABI (as opposed to SVR4/Linux), you can probably change this even
for non-altivec EABI, since libgcc doesn't get split up like that for
embedded systems and libgcc isn't part of the EABI and there hasn't
been any real C++ binary compatibility anyway.

>  >> /* No data type wants to be aligned rounder than this.  */
>  >> #undef	BIGGEST_ALIGNMENT
>  >> ! #define BIGGEST_ALIGNMENT ((TARGET_EABI && !TARGET_ALTIVEC_ABI) ? 64 : 128)
>  >> 
>  >> + /* An expression for the alignment of a structure field FIELD if the
>  >> +    alignment computed in the usual way is COMPUTED.  */
>  >> + #define ADJUST_FIELD_ALIGN(FIELD, COMPUTED)				      \
>  >> + 	((TARGET_ALTIVEC_ABI && TREE_CODE (TREE_TYPE (FIELD)) == VECTOR_TYPE) \
>  >> + 	 ? 128 : COMPUTED)
>  >> + 
>  >> + /* Define this macro as an expression for the alignment of a type
>  >> +    (given by TYPE as a tree node) if the alignment computed in the
>  >> +    usual way is COMPUTED and the alignment explicitly specified was
>  >> +    SPECIFIED.  */
>  >> + #define ROUND_TYPE_ALIGN(TYPE, COMPUTED, SPECIFIED)			\
>  >> + 	((TARGET_ALTIVEC_ABI && TREE_CODE (TYPE) == VECTOR_TYPE)	\
>  >> + 	 ? 128 : MAX (COMPUTED, SPECIFIED))
>  >> + 
>  >> #undef  BIGGEST_FIELD_ALIGNMENT
>  >> #undef  ADJUST_FIELD_ALIGN
>  >> 
>  >> /* Use ELF style section commands.  */
> 
>  > This has the same comment as the equivalent stuff in rs6000.h.
> 
> Huh?  What do you mean?

I had some comments about the changes in rs6000.h to BIGGEST_ALIGNMENT
etc.; these are the sysv4.h changes to BIGGEST_ALIGNMENT, and the same
comments apply.

> This is just for unnamed arguments in varargs.  So I'll have to add:
> 
>         if (cum->vregno <= ALTIVEC_ARG_MAX_REG && cum->nargs_prototype >= 0)
>                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> done. (?)

OK, whatever works.  I just wanted to be sure you knew about the
weirdness.

>  >> +       /* 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;
>  >> +       }
> 
>  > Do you really need this?  It looks just like the way a normal memory
>  > operand is printed (for the cases that are allowed for altivec).
> 
> Yes I do.  I want "[reg+reg]" to be outputed as "reg,reg" and [reg] to
> be outputed as "reg,0".
> 
> Consider "lvx d,a,b".  I want to match:
> 
>         (set (reg) (mem))
> 
> and have (mem) be dumped as "a,b" (the two registers in the memory
> address: (plus (reg) (reg))).  

I guess it's not quite the same as the behaviour for 'lwz', because of
the behaviour on just (reg).  This bit is OK, then.

>  > Can you put the altivec insns in their own .md file and use the include
>  > mechanism?  I believe this is what it was intended for.
> 
> As soon as you approve Alan's patch, yes :).

I'll look at it :-).

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>