From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114212 invoked by alias); 4 Apr 2019 05:40:30 -0000 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 Received: (qmail 114192 invoked by uid 89); 4 Apr 2019 05:40:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:562b40c, H*f:sk:562b40c X-HELO: mail-wr1-f46.google.com Received: from mail-wr1-f46.google.com (HELO mail-wr1-f46.google.com) (209.85.221.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 04 Apr 2019 05:40:28 +0000 Received: by mail-wr1-f46.google.com with SMTP id s15so1862364wra.12 for ; Wed, 03 Apr 2019 22:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:cc:from:message-id; bh=b/fOa812qAx/H4OCXjwi1rTNhMPC6E55+54mFVaNPFI=; b=hjMVMR3nqW4kb7yijYMi8auGW4vY8dwM+yp0a+UIn3+ki5PtvN8KDdLI7gN0WXSMSn M7VYeGghDhSgUsLyaU7M85DGyJU2PEUdLi9SUispa4rv74EWea2qd4dPOTGG3jpU/eI4 CNbgcTxdk8RSLVymDCUy7Z2xvYsRRMFk2P5xT9JgfFatgsVFyXBIKElpijxY0dwOn3pU fUToG+FMKDkPIktEv63k5hqPZk0ihWZCJfS++nGhdblT9yh9HmyWrvETq5sQrE1UwfVG Fb29IeP8AdrMYOOf02S+LgZoLVwul53SQAPoJmW2x0qW3pn2kxB5XXYmO9ksBsMa5XEN pvLw== Return-Path: Received: from [192.168.178.32] (x4d021249.dyn.telefonica.de. [77.2.18.73]) by smtp.gmail.com with ESMTPSA id s203sm33464484wmf.14.2019.04.03.22.40.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Apr 2019 22:40:24 -0700 (PDT) Date: Thu, 04 Apr 2019 05:40:00 -0000 User-Agent: K-9 Mail for Android In-Reply-To: <562b40ce-e818-d61d-c2e9-e06ee40369de@gmail.com> References: <562b40ce-e818-d61d-c2e9-e06ee40369de@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: vector alignment To: Martin Sebor CC: gcc mailing list From: Richard Biener Message-ID: <32554DB7-EB3B-4D6E-AB3E-EF43197E0AA8@gmail.com> X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00050.txt.bz2 On April 3, 2019 7:59:47 PM GMT+02:00, Martin Sebor wrot= e: >On 4/3/19 5:13 AM, Richard Biener wrote: >> On Tue, Apr 2, 2019 at 6:20 PM Martin Sebor wrote: >>> >>> GCC tries to align a vector on its natural boundary, i.e., that >>> given by its size, up to MAX_OBJECT_ALIGNMENT. Vectors that are >>> bigger than that are either silently [mis]aligned on that same >>> maximum boundary (PR 89798), silently truncated (and misaligned), >>> or cause an ICE (PR 89797). Compiling the following: >>> >>> __attribute__ ((vector_size (N))) char v; >>> >>> _Static_assert (sizeof (v) =3D=3D N, "size"); >>> _Static_assert (__alignof__ (v) =3D=3D N, "alignment"); >>> >>> with N set to 1LLU << I shows these failures: >>> >>> I < 29 succeeds >>> I < 31 fails alignment >>> I < 32 ICE >>> I >=3D 32 fails alignment and size >>> >>> Attribute aligned doesn't seem to have any effect on types or >>> variables declared with attribute vector_size. The alignment >>> set by the latter prevails. >>> >>> This happens no matter what scope the vector is defined in (i.e., >>> file or local). >>> >>> I have some questions: >>> >>> 1) Is there some reason to align vectors on the same boundary >>> as their size no matter how big it is? I can't find such >>> a requirement in the ABIs I looked at. Or would it be more >>> appropriate to align the big ones on the preferred boundary >>> for the target? For instance, does it make more sense to >>> align a 64KB vector on a 64KB boundary than on, say, >>> a 64-byte boundary (or some other boundary less than 64K?) >>=20 >> I don't think there's a good reason. Instead I think that >> BIGGEST_ALIGNMENT is what we should go for as upper limit, >> anything bigger doesn't make sense (unless the user explicitely >> requests it). > >Sounds good. Changing the alignment will impact object layout. Do we really apply the alignment there? How do other compilers lay out here= ?=20 >How do you suggest to deal with it? (Presumably for GCC 10.) >Issuing an ABI warning and adding an option to override >the new setting come to mind as possible mitigating solutions. We could reject these vector types in aggregates in favor of arrays. Of cou= rse that ship has sailed...=20 >>=20 >>> 2) If not, is it then appropriate to underalign very large >>> vectors on a boundary less than their size? >>=20 >> Yes. > >Ack. > >>=20 >>> 3) Should the aligned attribute not override the default vector >>> alignment? >>=20 >> Yes, but doesn't it already? > >Not if both are specified on the same declaration, as in: > > typedef __attribute__ ((aligned (1024), vector_size (256))) int V; > >I opened PR 89950 for this. > >Martin