From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 510953858D1E; Thu, 22 Dec 2022 18:41:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 510953858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 2BMIetAT007081; Thu, 22 Dec 2022 12:40:55 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 2BMIesuG007076; Thu, 22 Dec 2022 12:40:54 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 22 Dec 2022 12:40:54 -0600 From: Segher Boessenkool To: Richard Biener Cc: Jiufu Guo , gcc-patches@gcc.gnu.org, dje.gcc@gmail.com, linkw@gcc.gnu.org, jeffreyalaw@gmail.com Subject: Re: [PATCH] loading float member of parameter stored via int registers Message-ID: <20221222184054.GW25951@gate.crashing.org> References: <20221221062736.78036-1-guojiufu@linux.ibm.com> <58beeb5dd65a10b7480f73462da904a4@linux.ibm.com> <7ebknvhkun.fsf@pike.rch.stglabs.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_SHORT,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no 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 Thu, Dec 22, 2022 at 11:28:01AM +0000, Richard Biener wrote: > On Thu, 22 Dec 2022, Jiufu Guo wrote: > > To reduce risk, I'm just draft straightforward patches for > > special cases currently, Like: > > https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608081.html > > and this patch. > > Heh, yes - though I'm not fond of special-casing things. RTL > expansion is already full of special cases :/ And many of those are not useful at all (would be done by later passes), or are actively harmful. Not to mention that expand is currently one of the most impregnable and undebuggable RTL passes. But there are also many things done during expand that although they should be done somewhat later, aren't actually done later at all currently. So that needs fixing. Maybe things should go via an intermediate step, where all the decisions can be made, and then later we just have to translate the "low Gimple" or "RTL-Gimple" ("Rimple"?) to RTL. A format that is looser in many ways than either RTL or Gimple. A bit like Generic in that way. Segher