Re: [PATCH] Reload CONST_VECTOR into memory on ppc.

[Geoff Keating <geoffk at desire dot geoffk dot org>]

> X-Original-To: geoffk@foam.wonderslug.com
> Cc: Aldy Hernandez <aldyh@redhat.com>, "David Edelsohn" <edelsohn@us.ibm.com>,
>         gcc-patches@gcc.gnu.org, geoffk@geoffk.org
> From: "Hartmut Penner" <HPENNER@de.ibm.com>
> Date: Tue, 30 Dec 2003 10:42:03 +0100
> X-MIMETrack: Serialize by Router on D12ML006/12/M/IBM(Release 5.0.9a |January 7, 2002) at
>  30/12/2003 10:42:06
> X-OriginalArrivalTime: 30 Dec 2003 09:33:48.0953 (UTC) FILETIME=[075FD090:01C3CEB8]
> 
> "Geoffrey Keating <geoffk@geoffk.org> writes:
> 
> >> test.c:2888: error: unrecognizable insn:
> >> (insn 8625 5575 5570 510 (set (reg:V4SI 1)
> >>         (const_vector:V4SI [
> >>                 (const_int 65537 [0x10001])
> >>                 (const_int 65537 [0x10001])
> >>                 (const_int 65537 [0x10001])
> >>                 (const_int 65537 [0x10001])
> >>             ])) -1 (nil)
> >>     (nil))
> >> test.c:2888: internal compiler error: in extract_insn, at recog.c:2061
> >> Please submit a full bug report,
> >> with preprocessed source if appropriate.
> >> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> 
> > This insn should be recognizable; certainly, spilling to memory isn't
> > going to produce much better code.  Note that we are here loading
> > a CONST_VECTOR into *integer* registers.
> 
> > Probably you need to enhance movv4si_internal to handle this case.
> 
> I think, there are two thing we need to fix:
> 
> 1) Reload needs a hint what to do, if it gets a const_vector as operand,
>    which is not a 'easy' vector (loadable with a splash instruction). Even
>    if anything is done to prevent the compiler to produce such an insn with
>    a 'not easy' vector, due to some optimization as seen above such a const
>    might be produced. The change of PREFERED_RELOAD_CLASS will give reload
>    a needed hint, what to do, and is necessary for a robust compiler.

No.  Reload does not and should not expect that it can generate an
arbitrary load of any constant into any register directly in RTL.
LEGITIMATE_CONSTANT_P already rejects this constant, and that is all
the information reload should need.  How is this insn being generated?

> > 2) More VECTOR_CONST as now recognized are possible to load more efficient
>    as done right now. Even the one above can be loaded with 'vspltisb' into
> a
>    vector register. Also for loading this constant in integer register, we
> could
>    code appropriate splitter.
> 
> Locking at both 1) is necessary, 2) is a optimization.

I agree, this should be an 'easy' constant.

In fact, I suspect that what's really happened is that this used to be
a V8HI operation, which would be perfectly OK, and it got changed into
a V4SI operation.  We could write code to prevent reload from doing
this (and one day we'll need to), but since the machine can actually
handle this insn, it should be allowed.

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