From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by sourceware.org (Postfix) with ESMTPS id 3D93D3858412; Mon, 24 Oct 2022 12:46:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3D93D3858412 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id F20F21FD8E; Mon, 24 Oct 2022 12:46:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1666615609; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dmfZyUHVw5J1EESMfODzE6kMM1rnbtgv1P9ikvQt2uk=; b=zXIONY+Vsg6SXc3RsDQ4ScCKK3Ryzij+fpbB71DYsvwURGKeDb4HWeU0jheX+StoA26XGX mCunNR4tSP2ZISS4tSsYDpoFgZxFOFLXybzRSdNuxd5sP3tFzbeFE5SYpsiQ9xkugQkoDt JTR+j8SkuKjmMd8bOn+NmKo/sL94p6M= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1666615609; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dmfZyUHVw5J1EESMfODzE6kMM1rnbtgv1P9ikvQt2uk=; b=y7SxRDEdInYaBNsVSEMr/qKcpHqdqUYszPc0orD1J7+9Ylome5Sk9BFQCAU0mYEQ/wB2YP NCX9ezxGMeM1uZCQ== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id D5DD52C141; Mon, 24 Oct 2022 12:46:49 +0000 (UTC) Date: Mon, 24 Oct 2022 12:46:49 +0000 (UTC) From: Richard Biener To: "Andre Vieira (lists)" cc: "gcc-patches@gcc.gnu.org" , Richard Sandiford , ebotcazou@gcc.gnu.org Subject: Re: vect: Make vect_check_gather_scatter reject offsets that aren't multiples of BITS_PER_UNIT [PR107346] In-Reply-To: Message-ID: References: <129db1b0-0d2a-b768-bc80-9f73d665e8f8@arm.com> User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-1609957120-1568328364-1666615491=:4294" X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1609957120-1568328364-1666615491=:4294 Content-Type: text/plain; CHARSET=ISO-8859-15 Content-Transfer-Encoding: 8BIT On Mon, 24 Oct 2022, Andre Vieira (lists) wrote: > > On 24/10/2022 08:17, Richard Biener wrote: > > > > Can you check why vect_find_stmt_data_reference doesn't trip on the > > > > if (TREE_CODE (DR_REF (dr)) == COMPONENT_REF > > && DECL_BIT_FIELD (TREE_OPERAND (DR_REF (dr), 1))) > > { > > free_data_ref (dr); > > return opt_result::failure_at (stmt, > > "not vectorized:" > > " statement is an unsupported" > > " bitfield access %G", stmt); > > } > > It used to, which is why this test didn't trigger the error before my patch, > but we lower it to BIT_FIELD_REFs in ifcvt now so it is no longer a > DECL_BIT_FIELD. > > But that is a red-herring, if you change the test structure's 'type Int24 is > mod 2**24;' to 'type Int24 is mod 2**32;', thus making the field we access a > normal 32-bit integer, the field no longer is a DECL_BIT_FIELD and thus my > lowering does nothing. However, you will still get the failure because the > field before it is a packed 4-bit field, making the offset to the field we are > accessing less than BITS_PER_UNIT. Hmm, so the _intent_ of DECL_BIT_FIELD_REPRESENTATIVE is to definitely _not_ be a DECL_BIT_FIELD (well, that's the whole point!). So this shows an issue with setting up DECL_BIT_FIELD_REPRESENTATIVE? Of course for a type with an alignment less than BITS_PER_UNIT (is StructB actually such a type?) there cannot be a representative that isn't, so maybe we should then set DECL_BIT_FIELD on it with a condition like Eric mentions? > > ? I think we should amend this check and I guess that > > checking multiple_p on DECL_FIELD_BIT_OFFSET should be enough? > That won't work either, unless we do the same walk-through the full access as > we do in get_inner_reference. I suppose we should not "if-convert" bit field accesses with a DECL_BIT_FIELD representative. There isn't any benefit doing that (not for general bitfield lowering either). Richard. > Let me elaborate, the 'offending' stmt here is: > _ifc__23 = (*x_7(D))[_1].b.D.3707; > > And the struct in question is: > package Loop_Optimization23_Pkg is >   type Nibble is mod 2**4; >   type Int24  is mod 2**24; >   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; > > That D.3707 is the 'container'm i.e. the DECL_BIT_FIELD_REPRESENTATIVE of the > original bitfield of type Int24. > So in vect_find_stmt_data_reference , the dr is: (*x_7(D))[_1].b.D.3707 and > TREE_OPERAND (DR_REF (dr), 1): D.3707, > which has DECL_FIELD_BIT_OFFSET: 0 > > So that check would also pass. However, get_inner_reference, walks the full > access and comes across '.b', the member access for StructA inside StructB, > that has DECL_FIELD_BIT_OFFSET: 4 > Which is where we get into trouble. So to catch that here, we would need to do > the same type of walking through all the member accesses, like > get_inner_reference does. > > > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg) ---1609957120-1568328364-1666615491=:4294--