From patchwork Wed Nov 3 20:02:59 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Uros Bizjak X-Patchwork-Id: 70059 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 96999B6F10 for ; Thu, 4 Nov 2010 07:03:11 +1100 (EST) Received: (qmail 23574 invoked by alias); 3 Nov 2010 20:03:08 -0000 Received: (qmail 23546 invoked by uid 22791); 3 Nov 2010 20:03:06 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, TW_ZJ X-Spam-Check-By: sourceware.org Received: from mail-pz0-f47.google.com (HELO mail-pz0-f47.google.com) (209.85.210.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 03 Nov 2010 20:03:01 +0000 Received: by pzk34 with SMTP id 34so35087pzk.20 for ; Wed, 03 Nov 2010 13:02:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.114.11 with SMTP id m11mr5799128wfc.143.1288814579483; Wed, 03 Nov 2010 13:02:59 -0700 (PDT) Received: by 10.143.167.14 with HTTP; Wed, 3 Nov 2010 13:02:59 -0700 (PDT) Date: Wed, 3 Nov 2010 21:02:59 +0100 Message-ID: Subject: [PATCH, middle-end]: Fix also PR46292 (was: Fix PR 44569) From: Uros Bizjak To: Paolo Bonzini Cc: Richard Guenther , gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org, John David Anglin Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On Tue, Nov 2, 2010 at 7:31 PM, Paolo Bonzini wrote: >> >  Out of interest, is this canonical rtl?  I wasn't sure whether it >> >  should be a const_vector instead. >> >> We probably can end up with various non-canonical RTL in debug-insns >> (like we can end up with non-gimple trees in debug statements).  Sad >> but true. > > If the choice is between a CONST_VECTOR and a CONCATN, a precise definition > of the one that is incorrect (I don't know which) would be "wrong RTL" > rather than "non-canonical RTL". :) Apparently, some targets return CONCATN in TImode: (concatn:TI [ (const_int 1 [0x1]) (const_int 2 [0x2]) (const_int 3 [0x3]) (const_int 4 [0x4]) (const_int 1 [0x1]) (const_int 2 [0x2]) (const_int 3 [0x3]) (const_int 4 [0x4]) (const_int 1 [0x1]) (const_int 2 [0x2]) (const_int 3 [0x3]) (const_int 4 [0x4]) (const_int 1 [0x1]) (const_int 2 [0x2]) (const_int 3 [0x3]) (const_int 4 [0x4]) ]) This RTX breaks GET_MODE_INNER, but we can win the game with another trick in the sleeve: 2010-11-03 Uros Bizjak PR middle-end/46292 * lower-suberg.c (simplify_subreg_concatn): For VOIDmode elements, if the innermode is not vector mode, determine the mode of a subreg by using mode_for_size of inner_size. The patch was bootstrapped and regression tested on x86_64-pc-linux-gnu {,-m32}, it was also tested with the cross to hppa-unknown-linux-gnu (where it fixes ICE). OK for 4.3 - 4.6 ? Uros. Index: lower-subreg.c =================================================================== --- lower-subreg.c (revision 166266) +++ lower-subreg.c (working copy) @@ -411,10 +411,13 @@ simplify_subreg_concatn (enum machine_mo part = XVECEXP (op, 0, byte / inner_size); partmode = GET_MODE (part); + if (partmode == VOIDmode && VECTOR_MODE_P (innermode)) + partmode = GET_MODE_INNER (innermode); + if (partmode == VOIDmode) { - gcc_assert (VECTOR_MODE_P (innermode)); - partmode = GET_MODE_INNER (innermode); + enum mode_class mclass = GET_MODE_CLASS (innermode); + partmode = mode_for_size (inner_size * BITS_PER_UNIT, mclass, 0); } final_offset = byte % inner_size;