From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16713 invoked by alias); 24 Jul 2002 16:07:01 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 16454 invoked from network); 24 Jul 2002 16:06:54 -0000 Received: from unknown (HELO atlrel6.hp.com) (156.153.255.205) by sources.redhat.com with SMTP; 24 Jul 2002 16:06:54 -0000 Received: from hpda.cup.hp.com (hpda.cup.hp.com [15.75.208.53]) by atlrel6.hp.com (Postfix) with ESMTP id BFE9DBCB; Wed, 24 Jul 2002 12:06:51 -0400 (EDT) Received: from hpsje.cup.hp.com (hpsje.cup.hp.com [15.244.96.221]) by hpda.cup.hp.com (Postfix) with ESMTP id C0A16AEE8; Wed, 24 Jul 2002 09:06:50 -0700 (PDT) Received: (from sje@localhost) by hpsje.cup.hp.com (8.8.6 (PHNE_17190)/8.7.3 TIS Messaging 5.0) id JAA22239; Wed, 24 Jul 2002 09:06:50 -0700 (PDT) Date: Wed, 24 Jul 2002 14:11:00 -0000 From: Steve Ellcey Message-Id: <200207241606.JAA22239@hpsje.cup.hp.com> To: gcc@gcc.gnu.org Subject: Re: Vector modes under hppa64-hpu Cc: aldyh@redhat.com, dave@hiauly1.hia.nrc.ca Reply-To: sje@cup.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-07/txt/msg01165.txt.bz2 I was looking at simd-1.c on IA64 HP-UX and PA64 HP-UX and I think I have a fix for simd-1.c that works on IA64 all the time and on PA64 *if* I do not optimize. To get rid of the problem in emit_move_insn I made the change shown in the attached patch. The problem is that the size of V2SI is the same as UNITS_PER_WORD on a 64 bit machine so emit_move_insn_1 didn't handle it with its slow method but it also had no code to handle it directly before it got to this test. On a 32 bit machine this test would be true because V2SI is 8 bytes and UNITS_PER_WORD is 4. I modified the test to allow it to be true for vectors even if the size is not greater then UNITS_PER_WORD. Does this seem like a reasonable fix? Or should there be code to handle this somewhere else in emit_move_insn_1? I think the generated code would be correct, just slow, but that shouldn't matter if the platform we are on doesn't support VECTOR modes anyway. The problem I have with this patch, and the reason I haven't submitted it to gcc-patches is that even with this patch PA64 fails to compile simd-1.c at -O1 or higher optimizations. I get the following message: [hpsje - sje_simd] $ obj_pa64_gcc/gcc/cc1 -O1 simd-1.c bar simd-1.c: In function `bar': simd-1.c:7: internal compiler error: Internal compiler error in simplify_gen_subreg, at simplify-rtx.c:2598 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. I haven't figured out what the problem is here. Any ideas on what to be looking for? I wind up in simplify_gen_subreg with innermode == VOIDmode and outermode == DImode. op is "(clobber (const_int 0 [0x0]))" and byte is 0. Steve Ellcey sje@cup.hp.com *** expr.c@@/main/hp/LATEST Wed Jul 10 13:06:24 2002 --- expr.c Tue Jul 23 11:29:21 2002 *************** emit_move_insn_1 (x, y) *** 3043,3049 **** /* This will handle any multi-word mode that lacks a move_insn pattern. However, you will get better code if you define such patterns, even if they must turn into multiple assembler instructions. */ ! else if (GET_MODE_SIZE (mode) > UNITS_PER_WORD) { rtx last_insn = 0; rtx seq, inner; --- 3043,3050 ---- /* This will handle any multi-word mode that lacks a move_insn pattern. However, you will get better code if you define such patterns, even if they must turn into multiple assembler instructions. */ ! else if ((VECTOR_MODE_P (mode) && !VECTOR_MODE_SUPPORTED_P (mode)) ! || GET_MODE_SIZE (mode) > UNITS_PER_WORD) { rtx last_insn = 0; rtx seq, inner;