From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 643 invoked by alias); 15 Jun 2008 17:28:01 -0000 Received: (qmail 635 invoked by uid 22791); 15 Jun 2008 17:28:00 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate7.de.ibm.com (HELO mtagate7.de.ibm.com) (195.212.29.156) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 15 Jun 2008 17:27:39 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate7.de.ibm.com (8.13.8/8.13.8) with ESMTP id m5FHRZK2323802 for ; Sun, 15 Jun 2008 17:27:35 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m5FHRZdG2674884 for ; Sun, 15 Jun 2008 19:27:35 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m5FHRZBP021738 for ; Sun, 15 Jun 2008 19:27:35 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id m5FHRZDv021734; Sun, 15 Jun 2008 19:27:35 +0200 Message-Id: <200806151727.m5FHRZDv021734@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Sun, 15 Jun 2008 19:27:35 +0200 Subject: Re: [PATCH] Fix ICE in simplify_immed_subreg on SPU To: ebotcazou@adacore.com (Eric Botcazou) Date: Sun, 15 Jun 2008 17:43:00 -0000 From: "Ulrich Weigand" Cc: gcc-patches@gcc.gnu.org In-Reply-To: <200806151801.56141.ebotcazou@adacore.com> from "Eric Botcazou" at Jun 15, 2008 06:01:56 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2008-06/txt/msg00978.txt.bz2 Eric Botcazou wrote: > > It seems to me that having an address constant like the above appear > > within a CONST_VECTOR should be OK -- it just cannot be simplified > > by simplify_immed_subreg so that function should return NULL_RTX. > > No, we already ran into this on x86, CONST_VECTOR should only contain the > aforementioned 3 kinds of constants. Why is this? It seems constructing the vector in the constant pool and loading it from there is the most efficient way to load this particular vector on the SPU -- but I don't see how to express this in a different manner without using a CONST_VECTOR ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com