From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 5BED43858400 for ; Mon, 18 Oct 2021 11:53:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5BED43858400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 48C951FD6D; Mon, 18 Oct 2021 11:53:58 +0000 (UTC) Received: from murzim.suse.de (murzim.suse.de [10.160.4.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 42BE9A3B8A; Mon, 18 Oct 2021 11:53:58 +0000 (UTC) Date: Mon, 18 Oct 2021 13:53:58 +0200 (CEST) From: Richard Biener To: Prathamesh Kulkarni cc: gcc Patches Subject: Re: [match.pd] PR83750 - CSE erf/erfc pair In-Reply-To: Message-ID: <41ssp55p-1sp2-r9qs-n4po-poq797or90@fhfr.qr> References: <7nno61so-8qor-n16r-444p-527o2qp169r5@fhfr.qr> <92r13pn-97s9-r18r-6p8-96o3rqqn9or1@fhfr.qr> MIME-Version: 1.0 X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Mon, 18 Oct 2021 11:54:00 -0000 On Mon, 18 Oct 2021, Prathamesh Kulkarni wrote: > On Mon, 18 Oct 2021 at 17:10, Richard Biener wrote: > > > > On Mon, 18 Oct 2021, Prathamesh Kulkarni wrote: > > > > > On Mon, 18 Oct 2021 at 16:18, Richard Biener wrote: > > > > > > > > On Mon, 18 Oct 2021, Prathamesh Kulkarni wrote: > > > > > > > > > Hi Richard, > > > > > As suggested in PR, I have attached WIP patch that adds two patterns > > > > > to match.pd: > > > > > erfc(x) --> 1 - erf(x) if canonicalize_math_p() and, > > > > > 1 - erf(x) --> erfc(x) if !canonicalize_math_p(). > > > > > > > > > > This works to remove call to erfc for the following test: > > > > > double f(double x) > > > > > { > > > > > double g(double, double); > > > > > > > > > > double t1 = __builtin_erf (x); > > > > > double t2 = __builtin_erfc (x); > > > > > return g(t1, t2); > > > > > } > > > > > > > > > > with .optimized dump shows: > > > > > t1_2 = __builtin_erf (x_1(D)); > > > > > t2_3 = 1.0e+0 - t1_2; > > > > > > > > > > However, for the following test: > > > > > double f(double x) > > > > > { > > > > > double g(double, double); > > > > > > > > > > double t1 = __builtin_erfc (x); > > > > > return t1; > > > > > } > > > > > > > > > > It canonicalizes erfc(x) to 1 - erf(x), but does not transform 1 - > > > > > erf(x) to erfc(x) again > > > > > post canonicalization. > > > > > -fdump-tree-folding shows that 1 - erf(x) --> erfc(x) gets applied, > > > > > but then it tries to > > > > > resimplify erfc(x), which fails post canonicalization. So we end up > > > > > with erfc(x) transformed to > > > > > 1 - erf(x) in .optimized dump, which I suppose isn't ideal. > > > > > Could you suggest how to proceed ? > > > > > > > > I applied your patch manually and it does the intended > > > > simplifications so I wonder what I am missing? > > > Would it be OK to always fold erfc(x) -> 1 - erf(x) even when there's > > > no erf(x) in the source ? > > > > I do think it's reasonable to expect erfc to be available when erf > > is and vice versa but note both are C99 specified functions (either > > requires -lm). > OK, thanks. Would it be OK to commit the patch after bootstrap+test ? Yes, but I'm confused because you say the patch doesn't work for you? Btw, please add the testcase from the PR and also a testcase that shows the canonicalization is undone. Maybe you can also double-check that we handle x + erfc (x) because I see we associate that as (x + 1) - erf (x) which is then not recognized back to erfc. The less surprising (as to preserve the function called in the source) variant for the PR would be to teach CSE to lookup erf(x) when visiting erfc(x) and when found synthesize 1 - erf(x). That said, a mathematician should chime in on how important it is to preserve erfc vs. erf (precision or even speed). Thanks, Richard. > Thanks, > Prathamesh > > > > > Richard. > > > > > So for the following test: > > > double f(double x) > > > { > > > t1 = __builtin_erfc(x) > > > return t1; > > > } > > > > > > .optimized dump shows: > > > double f (double x) > > > { > > > double t1; > > > double _2; > > > > > > [local count: 1073741824]: > > > _2 = __builtin_erf (x_1(D)); > > > t1_3 = 1.0e+0 - _2; > > > return t1_3; > > > } > > > > > > while before patch, it has: > > > t1_4 = __builtin_erfc (x_2(D)); [tail call] > > > return t1_4; > > > > > > Thanks, > > > Prathamesh > > > > > > > > > > > Richard. > > > > > > > > > Thanks, > > > > > Prathamesh > > > > > > > > > > > > > -- > > > > Richard Biener > > > > SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, > > > > Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg) > > > > > > > -- > > Richard Biener > > SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, > > Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg) > -- Richard Biener SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)