From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20054 invoked by alias); 23 Mar 2011 10:38:24 -0000 Received: (qmail 20012 invoked by uid 22791); 23 Mar 2011 10:38:21 -0000 X-SWARE-Spam-Status: No, hits=-2.3 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; Wed, 23 Mar 2011 10:38:16 +0000 Received: by wwj40 with SMTP id 40so8938273wwj.8 for ; Wed, 23 Mar 2011 03:38:12 -0700 (PDT) Received: by 10.216.143.135 with SMTP id l7mr7180413wej.86.1300876692765; Wed, 23 Mar 2011 03:38:12 -0700 (PDT) Received: from richards-thinkpad (gbibp9ph1--blueice2n1.emea.ibm.com [195.212.29.75]) by mx.google.com with ESMTPS id s40sm158504weq.28.2011.03.23.03.38.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Mar 2011 03:38:11 -0700 (PDT) From: Richard Sandiford To: Richard Guenther Mail-Followup-To: Richard Guenther ,gcc@gcc.gnu.org, richard.sandiford@linaro.org Cc: gcc@gcc.gnu.org Subject: Re: RFC: Representing vector lane load/store operations References: <87k4frlz5c.fsf@firetop.home> Date: Wed, 23 Mar 2011 10:38:00 -0000 In-Reply-To: (Richard Guenther's message of "Wed, 23 Mar 2011 10:23:11 +0100") 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-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-03/txt/msg00342.txt.bz2 Richard Guenther writes: > But as you have partial defs of the vector lane array the simplest > approach is probably to not make them a register. Be prepared > for some surprises during RTL expansion though ;) OK. It's there I'd like to start, specifically with: These arrays of vectors would still need to have a non-BLK mode, so that they can be stored in _rtl_ registers. But we need that anyway for ARM's arm_neon.h; the code that today's GCC produces for the intrinsic functions is very poor. because I'd like to fix the bad code we generate for intrinsics. Thing is, this is going to be another case where the mode of a type depends on the current target. E.g. on ARM, we don't want to use a 24-byte mode for an array of 3 2xSI vectors unless V2SI is also available. Both the mode of the vector type and the mode of the array type will therefore depend on whether Neon is enabled. I know you don't like the way we handle TYPE_MODE for vectors: #define TYPE_MODE(NODE) \ (TREE_CODE (TYPE_CHECK (NODE)) == VECTOR_TYPE \ ? vector_type_mode (NODE) : (NODE)->type.mode) so I'm guessing you wouldn't be too happy to see ARRAY_TYPE popping up there as well. :-) What's the best way of handling this? Richard