From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2036 invoked by alias); 15 Dec 2014 21:32:29 -0000 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 Received: (qmail 2018 invoked by uid 89); 15 Dec 2014 21:32:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-wi0-f174.google.com Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com) (209.85.212.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 15 Dec 2014 21:32:27 +0000 Received: by mail-wi0-f174.google.com with SMTP id h11so10312016wiw.7; Mon, 15 Dec 2014 13:32:24 -0800 (PST) X-Received: by 10.180.107.198 with SMTP id he6mr35293518wib.44.1418679144233; Mon, 15 Dec 2014 13:32:24 -0800 (PST) Received: from localhost ([95.144.14.138]) by mx.google.com with ESMTPSA id ec2sm14681815wib.23.2014.12.15.13.32.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Dec 2014 13:32:23 -0800 (PST) From: Richard Sandiford To: Eric Botcazou Mail-Followup-To: Eric Botcazou ,Richard Sandiford , gcc-patches@gcc.gnu.org, Alan Hayward , "steven\@gcc.gnu.org" , rdsandiford@googlemail.com Cc: Richard Sandiford , gcc-patches@gcc.gnu.org, Alan Hayward , "steven\@gcc.gnu.org" Subject: Re: [PATCH][rtlanal.c][BE][1/2] Fix vector load/stores to not use ld1/st1 References: <7355255.n9uUnY8azR@polaris> <87fvch8eo0.fsf@e105548-lin.cambridge.arm.com> <2241316.8n9R8QCkJl@polaris> Date: Mon, 15 Dec 2014 21:56:00 -0000 In-Reply-To: <2241316.8n9R8QCkJl@polaris> (Eric Botcazou's message of "Mon, 15 Dec 2014 21:37:57 +0100") Message-ID: <87bnn4ha55.fsf@googlemail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2014-12/txt/msg01286.txt.bz2 Eric Botcazou writes: >> What do you think we should relax it to though? Obviously there's a balance >> here between relaxing things enough and not relaxing them too far (so that >> the EImode AArch64 thing I mentioned is still a noisy failure, for >> example). ISTM the patch deals with the only significant case that is >> obviously safe for modes that are not a power of 2 in size. > > Apparently the change wants to accept general subregs with not only modes > whose sizes are multiple of each other but also whose sizes are multiple of a > common large enough value. That clearly goes against: > > /* This should always pass, otherwise we don't know how to verify > the constraint. These conditions may be relaxed but > subreg_regno_offset would need to be redesigned. */ > gcc_assert ((GET_MODE_SIZE (xmode) % GET_MODE_SIZE (ymode)) == 0); > gcc_assert ((nregs_xmode % nregs_ymode) == 0); > > so I think that we should formulate the new requirement and implement it in > the main part of the function, instead of adding it as a kludge. Please be more specific though. If you don't think the patch is correct, what do you think the requirement should be and how should it be integrated into the existing checks? E.g. the assert is there because the main calculation is based on: /* Size of ymode must not be greater than the size of xmode. */ mode_multiple = GET_MODE_SIZE (xmode) / GET_MODE_SIZE (ymode); gcc_assert (mode_multiple != 0); which clearly isn't a useful value if the division isn't exact. Do you mean that, since mode_multiple isn't correct for the DI-of-a-CI case, we should reformulate the end of the function to avoid using mode_multiple at all? Thanks, Richard