This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: altivec: memory vector moves from GPRs
- From: Geoff Keating <geoffk at geoffk dot org>
- To: David Edelsohn <dje at watson dot ibm dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: 12 Feb 2002 15:41:35 -0800
- Subject: Re: altivec: memory vector moves from GPRs
- References: <200202122241.RAA30622@makai.watson.ibm.com>
David Edelsohn <dje@watson.ibm.com> writes:
> >>>>> Aldy Hernandez writes:
>
> Aldy> should i just commit and fix if some hunk of code generates a
> Aldy> subreg unexpectedly?
>
> Yeah, I guess so, unless Geoff objects.
>
> I'm just generally concerned that so many port throw around
> register_operand, which allows SUBREG and MEM, but then remove much more
> with the restriction.
>
> In other words, I don't know when to do:
>
> return (GET_CODE (op) == REG
> && (REGNO (op) > FIRST_PSEUDO_REGISTER
> || ALTIVEC_REGNO_P (REGNO (op))));
>
> versus
>
> return (register_operand (op, mode)
> && (GET_CODE (op) != REG
> || REGNO (op) > FIRST_PSEUDO_REGISTER
> || ALTIVEC_REGNO_P (REGNO (op))));
>
> In other words, when should the predicate restrict to only REG and when
> should the predicate allow a subset of register_operand.
I'm not sure of all the cases, but the obvious extra cases are:
(subreg:SI (reg:DI 1234) 4) # choosing one hard register out of a pseudo
(subreg:SI (reg:SF 1234) 0) # bitwise conversion of a pseudo
Typically, both of these become real hard registers after reload, but
before reload they are SUBREGs. You want to allow them everywhere
that you would allow the corresponding hard register, or reload will
create extra move operations.
The first case is unlikely with Altivec, perhaps, but the second case
could be quite common, from V4SI to V16QI or whatever.
--
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>