This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: AltiVec support toasted in HEAD
- From: Aldy Hernandez <aldyh at redhat dot com>
- To: Daniel Egger <degger at fhm dot edu>
- Cc: GCC Developer Mailinglist <gcc at gcc dot gnu dot org>
- Date: Fri, 5 Jul 2002 10:13:18 -0700
- Subject: Re: AltiVec support toasted in HEAD
- References: <1025821430.15397.3.camel@sonja.de.interearth.com>
On Fri, Jul 05, 2002 at 12:23:49AM +0200, Daniel Egger wrote:
> Hija,
>
> seems like the generic SIMD changes broke AltiVec support rather badly:
>
> x_ppc.c:605: error: unrecognizable insn:
> (insn:HI 397 396 398 1 (nil) (set (reg:V8HI 166)
> (const_vector:V8HI [
> (const_int 0 [0x0])
> (const_int 0 [0x0])
> (const_int 0 [0x0])
> (const_int 0 [0x0])
> (const_int 0 [0x0])
> (const_int 0 [0x0])
> (const_int 0 [0x0])
> (const_int 0 [0x0])
> ])) -1 (nil)
just a guess though...
the movv8hi_const0 pattern uses zero_constant:
(define_insn "*movv8hi_const0"
[(set (match_operand:V8HI 0 "altivec_register_operand" "=v")
(match_operand:V8HI 1 "zero_constant" ""))]
"TARGET_ALTIVEC"
"vxor %0,%0,%0"
[(set_attr "type" "vecsimple")])
zero_constant just matches CONST0_RTX(V8HImode), so if for some reason
whomever created the 0 const_vector did not use const_tiny_rtx[0][V8HImode]
for the zero constant, the pattern won't match.
if you can't provide a testcase, then perhaps you can debug it on your
environment. hack zero_constant() to abort when CONST0_RTX(mode) is not
true, but the vector elements are all zero. then break on the abort,
go up the call chain and you'll end up with the culprit who created this
nonsense.
aldy