From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 0BF1F3851C3D for ; Thu, 7 Jan 2021 14:20:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0BF1F3851C3D Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 107E3jjF046254; Thu, 7 Jan 2021 09:20:29 -0500 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 35x2hptj8r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 Jan 2021 09:20:29 -0500 Received: from m0098417.ppops.net (m0098417.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 107E5Lvi053198; Thu, 7 Jan 2021 09:20:28 -0500 Received: from ppma02wdc.us.ibm.com (aa.5b.37a9.ip4.static.sl-reverse.com [169.55.91.170]) by mx0a-001b2d01.pphosted.com with ESMTP id 35x2hptj8e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 Jan 2021 09:20:28 -0500 Received: from pps.filterd (ppma02wdc.us.ibm.com [127.0.0.1]) by ppma02wdc.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 107E6iMU010536; Thu, 7 Jan 2021 14:20:27 GMT Received: from b01cxnp23032.gho.pok.ibm.com (b01cxnp23032.gho.pok.ibm.com [9.57.198.27]) by ppma02wdc.us.ibm.com with ESMTP id 35tgf9d0td-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 Jan 2021 14:20:27 +0000 Received: from b01ledav006.gho.pok.ibm.com (b01ledav006.gho.pok.ibm.com [9.57.199.111]) by b01cxnp23032.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 107EKRT029950452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 7 Jan 2021 14:20:27 GMT Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 38F1FAC059; Thu, 7 Jan 2021 14:20:27 +0000 (GMT) Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 93741AC062; Thu, 7 Jan 2021 14:20:25 +0000 (GMT) Received: from work-tp (unknown [9.65.216.78]) by b01ledav006.gho.pok.ibm.com (Postfix) with ESMTPS; Thu, 7 Jan 2021 14:20:25 +0000 (GMT) Date: Thu, 7 Jan 2021 11:20:22 -0300 From: Raoni Fassina Firmino To: Jeff Law Cc: Richard Biener , jakub@redhat.com, segher@kernel.crashing.org, gcc-patches@gcc.gnu.org, joseph@codesourcery.com Subject: Re: [PATCH v5] rtl: builtins: (not just) rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193] Message-ID: <20210107142022.sw2nrq4s7imsy55y@work-tp> Mail-Followup-To: Jeff Law , Richard Biener , jakub@redhat.com, segher@kernel.crashing.org, gcc-patches@gcc.gnu.org, joseph@codesourcery.com References: <20201103231150.zlqccshb3qw63bdv@work-tp> <20201104151049.psotxu7xarcxmv5g@work-tp> <1c09d2bc-da08-523a-709d-ec11140af3f0@redhat.com> <3cda9726-6bdf-05bf-4168-42d3746a1665@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3cda9726-6bdf-05bf-4168-42d3746a1665@redhat.com> X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-07_06:2021-01-07, 2021-01-07 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 suspectscore=0 clxscore=1015 mlxlogscore=999 impostorscore=0 priorityscore=1501 bulkscore=0 phishscore=0 lowpriorityscore=0 adultscore=0 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101070088 X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 14:20:35 -0000 It seems to me we have two unrelated concerns mixed in the threads, I will reply in two different sub-threads to make this easier. This one to discuss the handling of target and output from the expands On Wed, Nov 18, 2020 at 02:45:44PM -0700, AL gcc-patches wrote: > > > On 11/18/20 12:31 AM, Richard Biener wrote: > > On Tue, 17 Nov 2020, Jeff Law wrote: > > > >> > >> On 11/4/20 8:10 AM, Raoni Fassina Firmino via Gcc-patches wrote: > >>> On Wed, Nov 04, 2020 at 10:35:03AM +0100, Richard Biener wrote: > >>>>> +/* Expand call EXP to the fegetround builtin (from C99 fenv.h), returning the > >>>>> + result and setting it in TARGET. Otherwise return NULL_RTX on failure. */ > >>>>> +static rtx > >>>>> +expand_builtin_fegetround (tree exp, rtx target, machine_mode target_mode) > >>>>> +{ > >>>>> + if (!validate_arglist (exp, VOID_TYPE)) > >>>>> + return NULL_RTX; > >>>>> + > >>>>> + insn_code icode = direct_optab_handler (fegetround_optab, SImode); > >>>>> + if (icode == CODE_FOR_nothing) > >>>>> + return NULL_RTX; > >>>>> + > >>>>> + if (target == 0 > >>>>> + || GET_MODE (target) != target_mode > >>>>> + || !(*insn_data[icode].operand[0].predicate) (target, target_mode)) > >>>>> + target = gen_reg_rtx (target_mode); > >>>>> + > >>>>> + rtx pat = GEN_FCN (icode) (target); > >>>>> + if (!pat) > >>>>> + return NULL_RTX; > >>>>> + emit_insn (pat); > >>>> I think you need to verify whether the expansion ended up in 'target' > >>>> and otherwise emit a move since usually 'target' is just a hint. > >>> I thought the "if (target == 0 ..." took care of that. The expands do > >>> emit a move, if that helps. > >> It looks like if we have a passed in target and it either has the wrong > >> mode or it does not match the predicate, then we generaet a new target > >> and use that instead.? I don't see where we'd copy from that new target > >> to the original desired target.? For some expanders the caller would > >> handle that, but I don't see how that's possible for this one without > >> the caller digging into the generated RTL to determine that > >> expand_builtin_fegetround put the result somewhere other than TARGET and > >> thus a copy is needed. > >> > >> That may be what Richi is worried about. > > I know we've added missing > > > > if (!rtx_equal_p (target, ops[0].value)) > > emit_move_insn (target, ops[0].value); > > > > to several expanders (using expand_insn rather than manual > > GEN_FCN (icode) calls). > Yes.  But I think we end up doing that mostly for expanders that return > the object where the value was stored in some reasonably convenient > location (either as a return value or in an ops array).  I don't think > that's the case here.  So, I think I got it wrong then, I thought the semantics where that the expander was responsible to provide a suitable target to the expand, and the expand was responsible to output to that target. That is how I created both, so if the expand can change the target maybe then it should be also responsible to generate the correct target. But this seems to me that we will have more repeated code for expands in different archs. o/ Raoni Fassina