From patchwork Tue Feb 27 07:04:09 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jiufu Guo X-Patchwork-Id: 56733 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 AA372385841D for ; Tue, 27 Feb 2024 12:37:20 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 790CF3858C35; Tue, 27 Feb 2024 12:36:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 790CF3858C35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 790CF3858C35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.158.5 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709037417; cv=none; b=IKFg8EB8CQ/CBPn9FrZV1q+wbgcOVKRvBHxcr7iM/xChyvgjFry1TjGs3sqGHVkgUb5w3d/ed3+GAWfglNvyBO23jYnW4GAyGifKSynrQvT3x9fuiZo2l8NZkgu9abNVMbYOtWhYSxVu+bcVSzZxQ6KD1LfEyiVErNonRjOqqZA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709037417; c=relaxed/simple; bh=eOUYxYb6QHDq502KS4L33842BRdv2h5KbIMz5M5lX3k=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=rGz0F57AhkKFTlkHfuGpIyCTwJcsqcIThXJfycwcjyfDTK/gu7jOhMPZRY5CbbAtdLFCkhyvfuGxM1TAcAq0Z/dHvw2gZtrcA+/7qetwumro5MgqVErdVdGO37k/D0PZm2RE2VOEZa20g/ySAxposWo/qIHUUdmLS2qgxsvVhwY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0353724.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 41RCI2Ub022215; Tue, 27 Feb 2024 12:36:50 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : date : message-id : content-transfer-encoding : mime-version; s=pp1; bh=F5DA6Z4SohrEbS90JK2jL0vzsTmPHHZG27czic8L9pk=; b=tGQ+DVUY+Ek+bFyEiNxCGMtOK0b3866yy2iYw4KOMu5e/uW6556FIZ7UHaYGjreqrtBX A/XYDb583fQwP0d/MIEy8gEEPoqv9SrBeVu/SNcwN+LXyjxCuU1tMT+e4E1Qp1MneVls BytCua/q3enqhbXjJtJ8ha77sD5fAJuDyrTLoVfwQ2FNnTfn75EOsvmKplRvmHCAvWGP Wa7fdO36g52rixCa4ePK+93iUCtSD7lPmp6aliu1Oe1Zj78qk2B9xvc+9oTKOsp5XkCb 1Ke7b+/ALc2VcN5Cqpo+q0DWRwwM0QiA9Cgeyi+Ya1OxoTAEFNYCZblcUgTZ6pAPaUdD iw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3whfm4gf3b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Feb 2024 12:36:50 +0000 Received: from m0353724.ppops.net (m0353724.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 41RCJPdR026727; Tue, 27 Feb 2024 12:36:49 GMT Received: from ppma21.wdc07v.mail.ibm.com (5b.69.3da9.ip4.static.sl-reverse.com [169.61.105.91]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3whfm4gf31-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Feb 2024 12:36:49 +0000 Received: from pps.filterd (ppma21.wdc07v.mail.ibm.com [127.0.0.1]) by ppma21.wdc07v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 41R9sHYr021267; Tue, 27 Feb 2024 12:36:48 GMT Received: from smtprelay04.fra02v.mail.ibm.com ([9.218.2.228]) by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 3wfusnykvg-9 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Feb 2024 12:36:48 +0000 Received: from smtpav06.fra02v.mail.ibm.com (smtpav06.fra02v.mail.ibm.com [10.20.54.105]) by smtprelay04.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 41R74FPj45810304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 27 Feb 2024 07:04:17 GMT Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E12262004B; Tue, 27 Feb 2024 07:04:14 +0000 (GMT) Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4F07720063; Tue, 27 Feb 2024 07:04:13 +0000 (GMT) Received: from genoa.aus.stglabs.ibm.com (unknown [9.40.192.157]) by smtpav06.fra02v.mail.ibm.com (Postfix) with ESMTP; Tue, 27 Feb 2024 07:04:13 +0000 (GMT) From: Jiufu Guo To: gcc-patches@gcc.gnu.org Cc: rguenther@suse.de, jeffreyalaw@gmail.com, richard.sandiford@arm.com, segher@kernel.crashing.org, dje.gcc@gmail.com, linkw@gcc.gnu.org, bergner@linux.ibm.com, guojiufu@linux.ibm.com Subject: [PATCH 0/3, RFC] fsra: Add final gimple sra before expander Date: Tue, 27 Feb 2024 15:04:09 +0800 Message-Id: <20240227070412.3471038-1-guojiufu@linux.ibm.com> X-Mailer: git-send-email 2.25.1 X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: jUQl2sKOY8-5DekxKW_-A0E1dS9nA4UD X-Proofpoint-GUID: Hngbt2Z7Zzy2tfSbmwDmxzDRAVyjrFLT X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-02-26_11,2024-02-27_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 lowpriorityscore=0 mlxlogscore=861 priorityscore=1501 suspectscore=0 adultscore=0 mlxscore=0 clxscore=1015 malwarescore=0 bulkscore=0 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2402270098 X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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 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 Hi, As known there are a few PRs (meta-bug PR101926) about accessing aggregate param/returns which are passed through registers. Given the suggestion from: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637935.html: We could even use the actual SRA pass in a special mode right before RTL expansion for the incoming/outgoing part. Compared to other solutions (e.g. previous light-sra-in-expander), this method could decouple the different parts (gimple-sra and rtl-expand), and could leverage the current SRA maximum. The following patches implements a prototype of this idea. In this prototype, only "parameters and returns" are treated as 'sra' candidates. If a 'parameter' is scalarized, then an IFN_ARG_PART is generated for the access at the beginning of the function, and if an access of a 'return' is scalarized, then IFN_SET_RET is generated for it. Those IFNs are expanded according to the incoming/outgoing registers for the accesses. Bootstrapped/regtested on ppc64{,le} and x86_64. In this prototype, there are still a few areas which can be enhanced, like: - Access multi-registers in one stmt, - Arg access across function calls, - More special target/ABI behavior, ... I would like to ask for comments/suggestions before jump into depth, to ensure this is in the correct direction, and to avoid missing some important thing. One thing/concern in this implementation: For an aggregate parameter, if it is not passed through registers, there is no need to scalarize in this sra. For example like i386/pr101908-3.c, Without sra, the stmts look like this: bar (); vect__1.5_10 = MEM [(double *)&x]; With sra, the stmts look like this: x_1 = .ARG_PART (x, 0, 128); bar (); vect__1.5_10 = x_1; The issue is that there are no instructions before invoking 'bar ()' without the patch; with the patch, instructions may be generated before 'bar ()' and those insns would not easy to be optimized by RTL passes. This would not be hard to fix (but maybe hacking): - Let 'sra' pass know the information about if the access is in the register, then avoid generating 'ARG_PART'. This would introduce coupling before gimple sra and rtl. - When expanding 'ARG_PART', if the access is in mem, then defer it. This would mean 'ARG_PART' may expand to nothing and make the dumped rtl is a little confused. Any comments? This prototype is splitted into three patches for review. 1/3: Add final gimple sra just before expander 2/3: Add support for ARG_PARTS 3/3: Add support for RET_PARTS Thanks for your comments and suggestions! BR, Jeff (Jiufu Guo)