From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16027 invoked by alias); 3 Apr 2019 11:14:09 -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 15588 invoked by uid 89); 3 Apr 2019 11:14:09 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=HTo:U*msebor, answer X-HELO: mail-lf1-f46.google.com Received: from mail-lf1-f46.google.com (HELO mail-lf1-f46.google.com) (209.85.167.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 03 Apr 2019 11:14:07 +0000 Received: by mail-lf1-f46.google.com with SMTP id o19so1045063lfl.4 for ; Wed, 03 Apr 2019 04:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1emF2LlU2DfSU1Y3uBKU7MNethPMqcocv9qTFVQcUVY=; b=NysIM3e3GLcBNIvwJrRw+mfYS2nm2PUrnxP+FHWF8ULQemY2tJJzGZweNQa+v8O5Ct jrRjTUhJFzHfVnny2Cs+F6CsBPS/UNWylAJsVRpjbWWsWO2L94CnlqkxGAlxo79S1Owv U4aRV7TjmaV/pXY9lmk2ssjgM4G6f6SnpBiOutV6HR4J1U+dwfaV6oNoWtX3REZVODK0 dlk3hlWr+0uhj9OwQbFaj8W8dfC3fVB2tEDByQ9y7+PryQG8a3UHhQlifztDviEmaWMP kqxetyJmi94HCeAnmNsfV9QZpp+coZXEucfFnOBAj02zvpKveGJ8XPiCr7UeRg10lzBE K63A== MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Wed, 03 Apr 2019 11:14:00 -0000 Message-ID: Subject: Re: vector alignment To: Martin Sebor Cc: gcc mailing list Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00036.txt.bz2 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) == N, "size"); > _Static_assert (__alignof__ (v) == N, "alignment"); > > with N set to 1LLU << I shows these failures: > > I < 29 succeeds > I < 31 fails alignment > I < 32 ICE > I >= 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?) 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). > 2) If not, is it then appropriate to underalign very large > vectors on a boundary less than their size? Yes. > 3) Should the aligned attribute not override the default vector > alignment? Yes, but doesn't it already? > I would like to think the answer to (1) is that vectors should > be aligned on the preferred boundary for the target/ABI. If > that's feasible, it should also obviate question (2). > > I believe the answer to (3) is yes. If not, GCC should issue > a warning that it doesn't honor the aligned attribute. > > Thanks > Martin