From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 949883860757; Fri, 28 Oct 2022 13:44:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 949883860757 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 74C441FB; Fri, 28 Oct 2022 06:44:22 -0700 (PDT) Received: from [10.57.2.23] (unknown [10.57.2.23]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7C5A73F445; Fri, 28 Oct 2022 06:44:15 -0700 (PDT) Message-ID: <0f38765b-3ca1-aee5-359e-ae10dd418433@arm.com> Date: Fri, 28 Oct 2022 14:43:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: vect: Make vect_check_gather_scatter reject offsets that aren't multiples of BITS_PER_UNIT [PR107346] To: Richard Biener Cc: "gcc-patches@gcc.gnu.org" , Richard Sandiford , ebotcazou@gcc.gnu.org References: <129db1b0-0d2a-b768-bc80-9f73d665e8f8@arm.com> <3cc86b91-eef3-7def-7b3b-464c58369f4b@arm.com> Content-Language: en-US From: "Andre Vieira (lists)" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-12.9 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,NICE_REPLY_A,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 24/10/2022 14:29, Richard Biener wrote: > On Mon, 24 Oct 2022, Andre Vieira (lists) wrote: > >> Changing if-convert would merely change this testcase but we could still >> trigger using a different structure type, changing the size of Int24 to 32 >> bits rather than 24: >> package Loop_Optimization23_Pkg is >>   type Nibble is mod 2**4; >>   type Int24  is mod 2**32;  -- Changed this from 24->32 >>   type StructA is record >>     a : Nibble; >>     b : Int24; >>   end record; >>   pragma Pack(StructA); >>   type StructB is record >>     a : Nibble; >>     b : StructA; >>   end record; >>   pragma Pack(StructB); >>   type ArrayOfStructB is array(0..100) of StructB; >>   procedure Foo (X : in out ArrayOfStructB); >> end Loop_Optimization23_Pkg; >> >> This would yield a DR_REF (dr): (*x_7(D))[_1].b.b  where the last 'b' isn't a >> DECL_BIT_FIELD anymore, but the first one still is and still has the >> non-multiple of BITS_PER_UNIT offset. Thus passing the >> vect_find_stmt_data_reference check and triggering the >> vect_check_gather_scatter failure. So unless we go and make sure we always set >> the DECL_BIT_FIELD on all subsequent accesses of a DECL_BIT_FIELD 'struct' >> (which is odd enough on its own) then we are better off catching the issue in >> vect_check_gather_scatter ? > But it's not only an issue with scatter-gather, other load/store handling > assumes it can create a pointer to the start of the access and thus > requires BITS_PER_UNIT alignment for each of them. So we need to fail > at data-ref analysis somehow. > > Richard. Sorry for the delay on this, had some other things come in between. After our IRC discussion I believe we agreed that it would be neater to check this in vect_check_gather_scatter as I did in the original patch in https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604139.html The main reasons being that to check earlier we'd need to walk the DR_REF to look for any FIELD_DECL that has DECL_BIT_FIELD set and we decided against that. Can you confirm the original patch is OK for trunk? Kind regards, Andre