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 BAEF03858CDA; Fri, 30 Dec 2022 07:45:21 +0000 (GMT) Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 2BU7iKas012212; Fri, 30 Dec 2022 01:44:21 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 2BU7iJJt012211; Fri, 30 Dec 2022 01:44:19 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 30 Dec 2022 01:44:19 -0600 From: Segher Boessenkool To: Jiufu Guo Cc: Jiufu Guo via Gcc-patches , Richard Biener , Richard Biener , 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: <20221230074419.GE25951@gate.crashing.org> References: <20221223165239.GA25951@gate.crashing.org> <20221223195207.GB25951@gate.crashing.org> <7ek02dft05.fsf@pike.rch.stglabs.ibm.com> <7e8ritexu0.fsf@pike.rch.stglabs.ibm.com> <7epmc1eil4.fsf@pike.rch.stglabs.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7epmc1eil4.fsf@pike.rch.stglabs.ibm.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-9.0 required=5.0 tests=BAYES_00,GIT_PATCH_0,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP 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: Hi! On Fri, Dec 30, 2022 at 10:22:31AM +0800, Jiufu Guo wrote: > Considering the limitations of CSE, I try to find other places > to handle this issue, and notice DSE can optimize below code: > "[sfp:DI]=x:DI ; y:SI=[sfp:DI]" to "y:SI=x:DI#0". > > So, I drafted a patch to update DSE to handle DI->DF/SF. > The patch updates "extract_low_bits" to get mode change > with subreg. > > diff --git a/gcc/expmed.cc b/gcc/expmed.cc > index b12b0e000c2..5e36331082c 100644 > --- a/gcc/expmed.cc > +++ b/gcc/expmed.cc > @@ -2439,7 +2439,10 @@ extract_low_bits (machine_mode mode, machine_mode src_mode, rtx src) > > if (!targetm.modes_tieable_p (src_int_mode, src_mode)) > return NULL_RTX; > - if (!targetm.modes_tieable_p (int_mode, mode)) > + if (!targetm.modes_tieable_p (int_mode, mode) > + && !(known_le (GET_MODE_BITSIZE (mode), GET_MODE_BITSIZE (src_mode)) > + && GET_MODE_CLASS (mode) == MODE_FLOAT > + && GET_MODE_CLASS (src_mode) == MODE_INT)) > return NULL_RTX; > > src = gen_lowpart (src_int_mode, src); Ah! This simply shows rs6000_modes_tieable_p is decidedly non-optimal: it does not allow tying a scalar float to anything else. No such thing is required, or good apparently. I wonder why we have such restrictions at all in rs6000; is it just unfortunate history, was it good at one point in time? Segher