From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17582 invoked by alias); 15 Jun 2008 22:24:43 -0000 Received: (qmail 17574 invoked by uid 22791); 15 Jun 2008 22:24:43 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 15 Jun 2008 22:24:23 +0000 Received: from zps75.corp.google.com (zps75.corp.google.com [172.25.146.75]) by smtp-out.google.com with ESMTP id m5FMMejO008628; Sun, 15 Jun 2008 23:22:41 +0100 Received: from smtp.corp.google.com (spacemonkey1.corp.google.com [192.168.120.115]) by zps75.corp.google.com with ESMTP id m5FMMdrt007906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 15 Jun 2008 15:22:40 -0700 Received: from localhost.localdomain.google.com (adsl-71-133-8-30.dsl.pltn13.pacbell.net [71.133.8.30]) (authenticated bits=0) by smtp.corp.google.com (8.13.8/8.13.8) with ESMTP id m5FMMcnI017900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 15 Jun 2008 15:22:39 -0700 To: "Ulrich Weigand" Cc: ebotcazou@adacore.com (Eric Botcazou), gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Fix ICE in simplify_immed_subreg on SPU References: <200806151727.m5FHRZDv021734@d12av02.megacenter.de.ibm.com> From: Ian Lance Taylor Date: Sun, 15 Jun 2008 22:25:00 -0000 In-Reply-To: <200806151727.m5FHRZDv021734@d12av02.megacenter.de.ibm.com> (Ulrich Weigand's message of "Sun\, 15 Jun 2008 19\:27\:35 +0200 \(CEST\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes 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/msg00996.txt.bz2 "Ulrich Weigand" writes: > 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 ... I think I'm with Ulrich here. A CONST_VECTOR containing a CONST seems reasonable to me. Eric, can you clarify what you see as the problem? Ian