From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 8A3B53858D33 for ; Thu, 9 Nov 2023 07:33:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8A3B53858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8A3B53858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.135.220.28 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699515244; cv=none; b=AO0KMkgiovADgV6ZMVVBAxGVlILkUSctzmslPEsTZxvkD46dnexHfxOJtfXonaKHp8sjQceOTBiwA44Xmuyh/abPbQgzmBxVaD1M/o71BqEPgEYMOB73RbG7+R2dgtE9DAPhCBFPIT35Cv+BitywIHQP6me9Ggaa0wIqstM5kKc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699515244; c=relaxed/simple; bh=Hq16PkMjd4mir40XyISIarGb4c7clFRFAqoHp2CA0bU=; h=DKIM-Signature:DKIM-Signature:Date:From:To:Subject:Message-ID: MIME-Version; b=c1FxaIsF9QY1oC2rpbH82kpr95hSWP/VW0TMCzcPUEuoGDufJ+EnNrN74yb7A8gfy30gEwr2G+aR6xqsJ9A8d+LBSgrBwCIdOml3W93hIi1V/QNvPKmjn9/Q4ptyU8DeBPQpoBWoaJoLCu9zf6Y8MqIl5MRhRfWfIn1gL1CfyJE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id AF95C2195D; Thu, 9 Nov 2023 07:33:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1699515237; 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=0G5qxX05kz//U43bKNNx8B2yilxEJRFFGrEOP7lBzxM=; b=OuCJPHnyS/9NqTWHKFePK4kDfgRD9x+GJAjlPV1Q3hOI0hpTerNn82qr9N0lKxeoK6Jc88 EERzB9ZFtsExC94RJh2kwWO3CSwQ9YxWEIXNrw2Q74Y94vzSIE1d7TtcSPXN478C/Lb6LY rx4qp/uVIFo1gVzxwDS9oMhLKp81ND4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1699515237; 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=0G5qxX05kz//U43bKNNx8B2yilxEJRFFGrEOP7lBzxM=; b=URSKDUex+rTZ23Af2fZP7JErarau+JLynhOMpHLo5RjiZj/ZAN2jMQ1GtYO/XlG6/tQnpi JB5gDaRldq60sQAQ== 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 28A1A2C43D; Thu, 9 Nov 2023 07:33:57 +0000 (UTC) Date: Thu, 9 Nov 2023 07:33:57 +0000 (UTC) From: Richard Biener To: Alexandre Oliva cc: gcc-patches@gcc.gnu.org, Rainer Orth , Mike Stump Subject: Re: [PATCH] testsuite: xfail scev-[35].c on ia32 In-Reply-To: Message-ID: References: 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=-10.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_NUMSUBJECT,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, 8 Nov 2023, Alexandre Oliva wrote: > > These gimplefe tests never got the desired optimization on ia32, but > they only started visibly failing when the representation of MEMs in > dumps changed from printing 'symbol: a' to '&a'. > > The transformation is not considered profitable on ia32, that's why it > doesn't take place. Maybe that's a bug in itself, but it's not a > regression, and not something to be noisy about. > > Regstrapped on x86_64-linux-gnu, also tested with gcc-13 on i686- and > x86_64-. Ok to install? OK. > (Richi, is the non-optimization choice on ia32 something unexpected that > ought to be looked into? I could file a PR, and maybe even look into it > a bit further.) There might be even a PR already. The testcase expects that IVOPTs chooses an IV that satisfies both a_p = &a[i_12]; and *&a[i_12] = 100; basically code-generating a LEA, a store of the address and an register indirect memory access. That's what happens for 64bit (and presumably on all other archs). For some reason (I can only guess costing), on ia32 we choose to prioritize using a single induction variable (we need the original GIV for the exit test) and so we get an obfuscated LEA for the address store and a base with scaled index access for the store. Note the testcase is a bit "bad" because we later sink the store to a_p, so the generated assembly for the ia32 looks actually better. Richard. > > for gcc/testsuite/ChangeLog > > * gcc.dg/tree-ssa/scev-3.c: xfail on ia32. > * gcc.dg/tree-ssa/scev-5.c: Likewise. > > Issue: gcc#155 > TN: W517-007 > --- > gcc/testsuite/gcc.dg/tree-ssa/scev-3.c | 2 +- > gcc/testsuite/gcc.dg/tree-ssa/scev-5.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c b/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c > index 4babd33f5c062..ac8c8d4519e30 100644 > --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c > +++ b/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c > @@ -40,4 +40,4 @@ __BB(6): > > } > > -/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" } } */ > +/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ia32 } } } */ > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c b/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c > index c2feebdfc2489..c911a9298866f 100644 > --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c > +++ b/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c > @@ -40,4 +40,4 @@ __BB(6): > > } > > -/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" } } */ > +/* { dg-final { scan-tree-dump-times "&a" 1 "ivopts" { xfail ia32 } } } */ > > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)