From patchwork Thu Jan 11 08:50:43 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Li, Pan2" X-Patchwork-Id: 83853 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8D6CB3857C73 for ; Thu, 11 Jan 2024 08:53:57 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by sourceware.org (Postfix) with ESMTPS id B82A2385800B for ; Thu, 11 Jan 2024 08:50:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B82A2385800B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=intel.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B82A2385800B Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=134.134.136.100 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704963064; cv=none; b=mapm/BJk3uZZnQ17N5Sy3QZkyXzD54HrRMhoqsS2T0Hkj2ZSsXsLhgpv6TK0Gyd59gwd3HiFZFiLZGesCKWiGrA2sQGsc7Xytqmh5E/GTSSNX2VR8kzY2TmJ9xMVMRZhaLqSpuV5/95Ed0xmfbH/r8Xl7c2jfz6DTlpZCCA5b9I= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704963064; c=relaxed/simple; bh=T8+SDSinsH963pTsBGmqzKaPLwa2asVb1FGL4hyii9w=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=KreL69VZ4cn/YD3OAi2uOjkaVlgH44q3Vd6WqA0mq/OeEeN2g1+GSMsh/XkINMTqFV/XNqdUHuTyy0iy6jwAyazVJNX7hccssqx1Jl60rkv9xw3lVPnqxYbMNUfgJws5rSnpIjZOh0XGZxaGJZqVdjMwOPqNnwfqZkIHL7KeTz8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1704963049; x=1736499049; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=T8+SDSinsH963pTsBGmqzKaPLwa2asVb1FGL4hyii9w=; b=IZUuF8iOGmU4jZbarnQCXIi/4Vt5Q8g4EcitiVsNUvgdX6sERKSXAboj uyDr9cJBISPcni24nKMH1OnFZyz8tOtMdr5h3k7zHbj10lC29izk51I0C O6VS2Fsfe1jTqIAVLgUFHGtdNbJGBww4lIeiqnKnyieB2guO3tE9GEPmp Dou8xYmc1J0D1q8e//c7EodfhUgNIk8b9tLdnFiuw8zes5kpySn97zj/B X3gqQJrL+pvhOJVGxvkLhjGKG7bUchto4Q7IZ0TBGB2waH0kwshzHeesb MRDa/OiyrKrJNB6RAali+8Qun1Raq9wN1D1M/z6z9/mAc2T2gy/Eojl78 w==; X-IronPort-AV: E=McAfee;i="6600,9927,10949"; a="465173058" X-IronPort-AV: E=Sophos;i="6.04,185,1695711600"; d="scan'208";a="465173058" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jan 2024 00:50:48 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10949"; a="901481419" X-IronPort-AV: E=Sophos;i="6.04,185,1695711600"; d="scan'208";a="901481419" Received: from shvmail03.sh.intel.com ([10.239.245.20]) by fmsmga002.fm.intel.com with ESMTP; 11 Jan 2024 00:50:45 -0800 Received: from pli-ubuntu.sh.intel.com (pli-ubuntu.sh.intel.com [10.239.159.47]) by shvmail03.sh.intel.com (Postfix) with ESMTP id 9521C100570F; Thu, 11 Jan 2024 16:50:44 +0800 (CST) From: pan2.li@intel.com To: gcc-patches@gcc.gnu.org Cc: juzhe.zhong@rivai.ai, pan2.li@intel.com, yanzhang.wang@intel.com, kito.cheng@gmail.com, richard.guenther@gmail.com, jeffreyalaw@gmail.com Subject: [PATCH v5] LOOP-UNROLL: Leverage HAS_SIGNED_ZERO for var expansion Date: Thu, 11 Jan 2024 16:50:43 +0800 Message-Id: <20240111085043.1246942-1-pan2.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20231223110733.2565292-1-pan2.li@intel.com> References: <20231223110733.2565292-1-pan2.li@intel.com> MIME-Version: 1.0 X-Spam-Status: No, score=-12.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_NONE, SPF_NONE, 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org From: Pan Li The insert_var_expansion_initialization depends on the HONOR_SIGNED_ZEROS to initialize the unrolling variables to +0.0f when -0.0f and no-signed-option. Unfortunately, we should always keep the -0.0f here because: * The -0.0f is always the correct initial value. * We need to support the target that always honor signed zero. Thus, we need to leverage MODE_HAS_SIGNED_ZEROS when initialize instead of HONOR_SIGNED_ZEROS. Then the target/backend can decide to honor the no-signed-zero or not. We also removed the testcase pr30957-1.c, as it makes undefined behavior whether the return value is positive or negative. The below tests are passed for this patch: * The riscv regression tests. * The aarch64 regression tests. * The x86 bootstrap and regression tests. gcc/ChangeLog: * loop-unroll.cc (insert_var_expansion_initialization): Leverage MODE_HAS_SIGNED_ZEROS for expansion variable initialization. gcc/testsuite/ChangeLog: * gcc.dg/pr30957-1.c: Remove. Signed-off-by: Pan Li --- gcc/loop-unroll.cc | 4 ++-- gcc/testsuite/gcc.dg/pr30957-1.c | 36 -------------------------------- 2 files changed, 2 insertions(+), 38 deletions(-) delete mode 100644 gcc/testsuite/gcc.dg/pr30957-1.c diff --git a/gcc/loop-unroll.cc b/gcc/loop-unroll.cc index 4176a21e308..bfdfe6c2bb7 100644 --- a/gcc/loop-unroll.cc +++ b/gcc/loop-unroll.cc @@ -1855,7 +1855,7 @@ insert_var_expansion_initialization (struct var_to_expand *ve, rtx var, zero_init; unsigned i; machine_mode mode = GET_MODE (ve->reg); - bool honor_signed_zero_p = HONOR_SIGNED_ZEROS (mode); + bool has_signed_zero_p = MODE_HAS_SIGNED_ZEROS (mode); if (ve->var_expansions.length () == 0) return; @@ -1869,7 +1869,7 @@ insert_var_expansion_initialization (struct var_to_expand *ve, case MINUS: FOR_EACH_VEC_ELT (ve->var_expansions, i, var) { - if (honor_signed_zero_p) + if (has_signed_zero_p) zero_init = simplify_gen_unary (NEG, mode, CONST0_RTX (mode), mode); else zero_init = CONST0_RTX (mode); diff --git a/gcc/testsuite/gcc.dg/pr30957-1.c b/gcc/testsuite/gcc.dg/pr30957-1.c deleted file mode 100644 index 564410913ab..00000000000 --- a/gcc/testsuite/gcc.dg/pr30957-1.c +++ /dev/null @@ -1,36 +0,0 @@ -/* { dg-do run { xfail { mmix-*-* } } } */ -/* We don't (and don't want to) perform this optimisation on soft-float targets, - where each addition is a library call. / -/* { dg-require-effective-target hard_float } */ -/* -fassociative-math requires -fno-trapping-math and -fno-signed-zeros. */ -/* { dg-options "-O2 -funroll-loops -fassociative-math -fno-trapping-math -fno-signed-zeros -fvariable-expansion-in-unroller -fdump-rtl-loop2_unroll" } */ - -extern void abort (void); -extern void exit (int); - -float __attribute__((noinline)) -foo (float d, int n) -{ - unsigned i; - float accum = d; - - for (i = 0; i < n; i++) - accum += d; - - return accum; -} - -int -main () -{ - /* When compiling standard compliant we expect foo to return -0.0. But the - variable expansion during unrolling optimization (for this testcase enabled - by non-compliant -fassociative-math) instantiates copy(s) of the - accumulator which it initializes with +0.0. Hence we expect that foo - returns +0.0. */ - if (__builtin_copysignf (1.0, foo (0.0 / -5.0, 10)) != 1.0) - abort (); - exit (0); -} - -/* { dg-final { scan-rtl-dump "Expanding Accumulator" "loop2_unroll" { xfail mmix-*-* } } } */