From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by sourceware.org (Postfix) with ESMTPS id A806A3858D28 for ; Thu, 16 Dec 2021 17:25:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A806A3858D28 Received: by mail-wr1-x435.google.com with SMTP id i22so15689393wrb.13 for ; Thu, 16 Dec 2021 09:25:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=TBIupuuBtQiI6UF1014A55+TiQ2iXAHp1J6ARGLeqOE=; b=kE64RRC4LoT/k1TSwCbggRR3ok+qp73T01X0sq+6NpeCicv6T/fWVu4a1ioalCzNF7 1f7a259+3GI3J+lo8oIVFpdevT2nBsRSs0os920I8D5k1vI6SY4Wf3/+vTV/SExaFB1+ eWpBrGTl0pi3beOzeN1OzD3nuM4efA0djBhj20uS4YghIhclP7uviyczVR0/9/j92rzP Tb+CJt0ebSlYJoRaak1uQy+oWJCf6B0TO8s4bhp02Tbl0dtZc5zWFEkaeRlCcfQvttwc bHGafeaR2Fvh943XAFwJbl0jAS7MPEhK0GEDkCLUenNH8TTKajmnIjy9eCAJfFLzgkZu mteg== X-Gm-Message-State: AOAM533pBqFcXSlSzIMV788Ok4ABZsxkAT3t4OktyBQhqHcoYr9uRaUO QC5CcgzOadNg5wF+1R61GUdDbw== X-Google-Smtp-Source: ABdhPJy8n3x8gNxRbwXSDAvCr8+BGHfFoG/7pmjN5mBQqHCZKyoVxEmLAhDiLOlihXdkyzZ3J/WM2Q== X-Received: by 2002:a5d:6d88:: with SMTP id l8mr10278551wrs.270.1639675512737; Thu, 16 Dec 2021 09:25:12 -0800 (PST) Received: from fomalhaut.localnet ([2a01:e0a:41b:84f0:cf71:f5e0:b050:bede]) by smtp.gmail.com with ESMTPSA id h15sm9944524wmq.32.2021.12.16.09.25.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Dec 2021 09:25:12 -0800 (PST) From: Eric Botcazou X-Google-Original-From: Eric Botcazou To: richard.sandiford@arm.com Cc: gcc-patches@gcc.gnu.org, Marc =?ISO-8859-1?Q?Poulhi=E8s?= Subject: Re: [PATCH] testsuite: Robustify aarch64/simd tests against more aggressive DCE Date: Thu, 16 Dec 2021 18:24:56 +0100 Message-ID: <12914311.uLZWGnKmhe@fomalhaut> In-Reply-To: References: <87a6h4jnry.fsf@adacore.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 17:25:15 -0000 > The calls should still be diagnosed as incorrect, even if we don't > code-generate them. The fact that we don't do that is a known bug > (in aarch64 code). OK, thanks for the explanation. > The new variables seem to be unused, so I think slightly stronger > DCE could remove the calls even after the patch. Perhaps the containing > functions should take an int32x4_t *ptr or something, with the calls > assigning to different ptr[] indices. We run a minimal DCE pass at -O0 in our compiler to eliminate all the garbage generated by the gimplifier for variable-sized types (people care about code size at -O0 in specific contexts) but it does not touch anything written by the user (and debugging is unaffected of course). Given that the builtins are pure functions and the arguments have no side effects, it eliminates the calls, but adding a LHS blocks that because this minimal DCE pass preserves anything user-related, in particular assignments to user variables. > I think it would be better to do that using new calls though, > and xfail the existing ones when they no longer work. For example: > > /* { dg-error "lane -1 out of range 0 - 7" "" {target *-*-*} 0 } */ > vqdmlal_high_laneq_s16 (int32x4_a, int16x8_b, int16x8_c, -1); > /* { dg-error "lane -1 out of range 0 - 7" "" {target *-*-*} 0 } */ > ptr[0] = vqdmlal_high_laneq_s16 (int32x4_a, int16x8_b, int16x8_c, -1); > > That way we don't lose the existing tests. Frankly I'm not quite sure of what we can lose by adding a LHS here, can you elaborate a bit? We would need a solution that works out of the box with our compiler in the future, i.e. without having to tweak 50 testcases again. -- Eric Botcazou