From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121116 invoked by alias); 4 Apr 2019 16:14:23 -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 121106 invoked by uid 89); 4 Apr 2019 16:14:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=tops, H*i:sk:32554DB, HX-Languages-Length:3433, H*f:sk:32554DB X-HELO: mail-qk1-f177.google.com Received: from mail-qk1-f177.google.com (HELO mail-qk1-f177.google.com) (209.85.222.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 04 Apr 2019 16:14:21 +0000 Received: by mail-qk1-f177.google.com with SMTP id s81so1959030qke.13 for ; Thu, 04 Apr 2019 09:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=apY3OtzseLvTRDvuIwpm86aNLUb95Do0mKg0eL079JI=; b=D2+mwIWdYrgnksWJFN6yZeZMrVLF9kmCA2vPL7Sz/VC9fczZRfjIp8BzG3C1otCw3a bZe78NEw1ylbVsJm+ayS+owHZWVPoAga7OJQ6YXWGEKgzD1uBB6zYr0FykRH6fV5mK2h UvIFNbZ4qEM1s/grabdtodKWJHH6u/6dlH0Y8YoyL/gltAj3qweU4lkcgnMnbC2J2KWk R6TjOpIIVZKwpUR7KA0/0+gaoTWuVNPcVn1+uQKq+CZPzXnm0NpocZLkSPTCXySbK2Nn oW9+sujvNs5d2lfazoDQOs6kxg9HHyBCf9cu3De3IINAlUpSXeCWVrzfKIv/HFT+fNbf z2qA== Return-Path: Received: from [192.168.0.41] (75-166-119-163.hlrn.qwest.net. [75.166.119.163]) by smtp.gmail.com with ESMTPSA id w18sm15830366qta.2.2019.04.04.09.14.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Apr 2019 09:14:18 -0700 (PDT) Subject: Re: vector alignment To: Richard Biener Cc: gcc mailing list References: <562b40ce-e818-d61d-c2e9-e06ee40369de@gmail.com> <32554DB7-EB3B-4D6E-AB3E-EF43197E0AA8@gmail.com> From: Martin Sebor Message-ID: <43c10644-2ce7-155e-6dbf-e37ac81b72ab@gmail.com> Date: Thu, 04 Apr 2019 16:14:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <32554DB7-EB3B-4D6E-AB3E-EF43197E0AA8@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00068.txt.bz2 On 4/3/19 11:40 PM, Richard Biener wrote: > On April 3, 2019 7:59:47 PM GMT+02:00, Martin Sebor wrote: >> 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) == 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). >> >> Sounds good. Changing the alignment will impact object layout. > > Do we really apply the alignment there? How do other compilers lay out here? Unfortunately, yes. The struct below is 2048 in size. struct S { char c; __attribute__ ((vector_size (1024))) char a; }; Clang and ICC do the same thing. The biggest vector Clang allows is 1024 bytes. ICC tops out at 1<<21. GCC ICEs for sizes over 1LLU << 32 but with my patch for bug 89797 it accepts any size up to 1/2 the address space. With types other than char the aligned attribute can be used in conjunction with packed to reduce the size to just 1088: struct S { char c; __attribute__ ((aligned (64), packed, vector_size (1024))) int a; }; All three compilers require the packed attribute to reduce the alignment. Clang and GCC silently ignore the aligned attribute without it but ICC issues warning #1366: a reduction in alignment without the "packed" attribute is ignored. That would be a helpful enhancement to add to GCC. I think ignoring the packed attribute for char vectors is a bug so I opened PR 89968 for it. >> 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 course that ship has sailed... We could still issue a warning for vectors that are excessively overaligned and suggest to use attributes aligned and packed to reduce the alignment. Martin