From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 6713A3858D28 for ; Thu, 22 Jun 2023 06:39:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6713A3858D28 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 50AC420391; Thu, 22 Jun 2023 06:39:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1687415962; 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=xDzRTRbNVpYLmPHdkb7HbABQx4ETs7EdDeyHVOE+xJ4=; b=yW+rCVKubNebBJrXaFTFrQWi6DwKTJUlfsFBDZnVlo07WsQQG0iN1Pxb7nzvUr0XM8AkSh V/AJhir05pmBJxxLeSJMyQD1cdUF6bBuTiGb1qnnF1UMr46lqpt/0CjPvW3jHgP5oeomlk 01SrxH18OhEOophoX4or6iIl9VYBtMU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1687415962; 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=xDzRTRbNVpYLmPHdkb7HbABQx4ETs7EdDeyHVOE+xJ4=; b=A4C+cDj9jtjKPUIqAtKREEK/nb3d8dM2ye3iF5nlRO00vIFBI+/k6CqQhRTWdyed41sZRE EW04yysqPZwJ4sDA== 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 4580C2C141; Thu, 22 Jun 2023 06:39:22 +0000 (UTC) Date: Thu, 22 Jun 2023 06:39:22 +0000 (UTC) From: Richard Biener To: Jeff Law cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH][RFC] middle-end/110237 - wrong MEM_ATTRs for partial loads/stores In-Reply-To: <08e73abd-ecb0-1b5c-6f78-f4c53d095f0a@gmail.com> Message-ID: References: <20230621074951.F3C3C3858433@sourceware.org> <08e73abd-ecb0-1b5c-6f78-f4c53d095f0a@gmail.com> User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: On Wed, 21 Jun 2023, Jeff Law wrote: > > > On 6/21/23 01:49, Richard Biener via Gcc-patches wrote: > > The following addresses a miscompilation by RTL scheduling related > > to the representation of masked stores. For that we have > > > > (insn 38 35 39 3 (set (mem:V16SI (plus:DI (reg:DI 40 r12 [orig:90 _22 ] > > [90]) > > (const:DI (plus:DI (symbol_ref:DI ("b") [flags 0x2] > > ) > > (const_int -4 [0xfffffffffffffffc])))) [1 MEM > > [(int *)vectp_b.12_28]+0 S64 A32]) > > (vec_merge:V16SI (reg:V16SI 20 xmm0 [118]) > > (mem:V16SI (plus:DI (reg:DI 40 r12 [orig:90 _22 ] [90]) > > (const:DI (plus:DI (symbol_ref:DI ("b") [flags 0x2] > > ) > > (const_int -4 [0xfffffffffffffffc])))) [1 MEM > > [(int *)vectp_b.12_28]+0 S64 > > A32]) > > > > and specifically the memory attributes > > > > [1 MEM [(int *)vectp_b.12_28]+0 S64 A32] > > > > are problematic. They tell us the instruction stores and reads a full > > vector which it if course does not. There isn't any good MEM_EXPR > > we can use here (we lack a way to just specify a pointer and restrict > > info for example), and since the MEMs have a vector mode it's > > difficult in general as passes do not need to look at the memory > > attributes at all. > > > > The easiest way to avoid running into the alias analysis problem is > > to scrap the MEM_EXPR when we expand the internal functions for > > partial loads/stores. That avoids the disambiguation we run into > > which is realizing that we store to an object of less size as > > the size of the mode we appear to store. > > > > After the patch we see just > > > > [1 S64 A32] > > > > so we preserve the alias set, the alignment and the size (the size > > is redundant if the MEM insn't BLKmode). That's still not good > > in case the RTL alias oracle would implement the same > > disambiguation but it fends off the gimple one. > > > > This fixes gcc.dg/torture/pr58955-2.c when built with AVX512 > > and --param=vect-partial-vector-usage=1. > > > > On the MEM_EXPR side we could use a CALL_EXPR and on the RTL > > side we might instead want to use a BLKmode MEM? Any better > > ideas here? > I'd expect that using BLKmode will fend off the RTL aliasing code. I suspect there's no way to specify the desired semantics? OTOH code that looks at the MEM operand only and not the insn (which should have some UNSPEC wrapped) needs to be conservative, so maybe the alias code shouldn't assume that a (mem:V16SI ..) actually performs an access of the size of V16SI at the specified location? Anyway, any opinion on the actual patch? It's enough to fix the observed miscompilation. Thanks, Richard.