From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15101 invoked by alias); 24 Mar 2011 10:57:16 -0000 Received: (qmail 15091 invoked by uid 22791); 24 Mar 2011 10:57:16 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 24 Mar 2011 10:57:10 +0000 Received: by wwj40 with SMTP id 40so10404645wwj.8 for ; Thu, 24 Mar 2011 03:57:09 -0700 (PDT) Received: by 10.216.143.74 with SMTP id k52mr1607308wej.0.1300964229470; Thu, 24 Mar 2011 03:57:09 -0700 (PDT) Received: from richards-thinkpad (gbibp9ph1--blueice2n1.emea.ibm.com [195.212.29.75]) by mx.google.com with ESMTPS id r57sm3693846wes.1.2011.03.24.03.57.08 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Mar 2011 03:57:08 -0700 (PDT) From: Richard Sandiford To: Chung-Lin Tang Mail-Followup-To: Chung-Lin Tang ,gcc-patches , richard.sandiford@linaro.org Cc: gcc-patches Subject: Re: [patch] Fix PR48183, NEON ICE in emit-rtl.c:immed_double_const() under -g References: <4D85DEA1.6070606@codesourcery.com> Date: Thu, 24 Mar 2011 10:57:00 -0000 In-Reply-To: <4D85DEA1.6070606@codesourcery.com> (Chung-Lin Tang's message of "Sun, 20 Mar 2011 20:01:53 +0900") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2011-03/txt/msg01585.txt.bz2 Chung-Lin Tang writes: > PR48183 is a case where ARM NEON instrinsics, under -O -g, produce debug > insns that tries to expand OImode (32-byte integer) zero constants, much > too large to represent as two HOST_WIDE_INTs; as the internals manual > indicates, such large constants are not supported in general, and ICEs > on the GET_MODE_BITSIZE(mode) == 2*HOST_BITS_PER_WIDE_INT assertion. > > This patch allows the cases where the large integer constant is still > representable using a single CONST_INT, such as zero(0). Bootstrapped > and tested on i686 and x86_64, cross-tested on ARM, all without > regressions. Okay for trunk? > > Thanks, > Chung-Lin > > 2011-03-20 Chung-Lin Tang > > * emit-rtl.c (immed_double_const): Allow wider than > 2*HOST_BITS_PER_WIDE_INT mode constants when they are > representable as a single const_int RTX. I realise this might be seen as a good expedient fix, but it makes me a bit uneasy. Not a very constructive rationale, sorry. For this particular case, the problem is that vst2q_s32 and the like initialise a union directly: union { int32x4x2_t __i; __builtin_neon_oi __o; } __bu = { __b; }; and this gets translated into a zeroing of the whole union followed by an assignment to __i: __bu = {}; __bu.__i = __b; We later optimise away the first assignment, but it still exists in the debug info. Another expedient fix might be to replace these initialisations with: union { int32x4x2_t __i; __builtin_neon_oi __o; } __bu; __bu.__i = __b; so that we never get a zeroing statement. I realise both "fixes" are papering over the real problem. What we really need is arbitrary-length constant integers, like we already have for vectors. But that's going to be a much bigger patch. It just seems to me that, if we're going for a work-around, the arm_neon.h change is neutral, while changing immed_double_const feels more risky. Richard