From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by sourceware.org (Postfix) with ESMTPS id D22FF3858D20 for ; Tue, 1 Feb 2022 07:04:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D22FF3858D20 Received: by mail-ej1-x633.google.com with SMTP id a8so50868495ejc.8 for ; Mon, 31 Jan 2022 23:04:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5enUq/6/IkPi6BTuABLicd5TmqYvCIQ9SDag/XhcRkE=; b=Y02U0l/iolgTyKBJIHckMY/MUIrLGWvjo6VNeRESSBQ2N4AEdP9Bxck0o2jqSHCOwn m939Q8KOnwTPHOoslv76oThwRPBh9rFVYv3+zY63Dyv1wWWGgkvikw1oDlf/x34ZNDt/ Qqulucc5wi0xpEV8m9Rbg9oTkZF9tisd9gI1N9E6AuEA/d8Ix1YDwodsbHdcmFRTH+ZY sIx2+TFqyYxkbBSB3AmKM08luWrP21tK46dGHlDpv482c4chgs/4Nxqyzy5tNtyS21zm nJzGwYUovGHERMOrco2qsvpcsMU4IJl1V8xGOBfLbqaDC8j9E3Ib2UD1Aa8v56xuv0vq LrKA== X-Gm-Message-State: AOAM531S+ifc8umQ4mSYXOq4ho/28nPcJgN5epV8irsbrJAyBzJ9R7U7 yJ3Gwl4RQD63312HERicRH40x8CBTbCt/MF0yhU= X-Google-Smtp-Source: ABdhPJxBxTRGYeMIjVhn7A4Q4egQLpYYlp69KHa22whoRZlFgcjZPM9nAEY1u5rZBdNQEsTC/8VEhGsqdbZ3kEfdwLM= X-Received: by 2002:a17:906:99c5:: with SMTP id s5mr20131973ejn.497.1643699088547; Mon, 31 Jan 2022 23:04:48 -0800 (PST) MIME-Version: 1.0 References: <57323305-3384-e128-4627-ad26969a36f3@suse.de> <3b14d728-35d3-251a-44b8-e152b92d5dd5@suse.de> In-Reply-To: <3b14d728-35d3-251a-44b8-e152b92d5dd5@suse.de> From: Richard Biener Date: Tue, 1 Feb 2022 08:04:37 +0100 Message-ID: Subject: Re: [PATCH][ldist] Don't add lib calls with -fno-tree-loop-distribute-patterns To: Tom de Vries Cc: Stefan Schulze Frielinghaus , GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-8.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Tue, 01 Feb 2022 07:04:51 -0000 On Mon, Jan 31, 2022 at 5:26 PM Tom de Vries wrote: > > [ was: Re: [RFC] ldist: Recognize rawmemchr loop patterns ] > > On 1/31/22 16:00, Richard Biener wrote: > >> I'm running into PR56888 ( > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 ) on nvptx due to > >> this, f.i. in gcc/testsuite/gcc.c-torture/execute/builtins/strlen.c, > >> where gcc/testsuite/gcc.c-torture/execute/builtins/lib/strlen.c contains > >> a strlen function, with a strlen loop, which is transformed by > >> pass_loop_distribution into a __builtin_strlen, which is then expanded > >> into a strlen call, creating a self-recursive function. [ And on nvptx, > >> that happens to result in a compilation failure, which is how I found > >> this. ] > >> > >> According to this ( > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888#c21 ) comment: > >> ... > >> -fno-tree-loop-distribute-patterns is the reliable way to not > >> transform loops into library calls. > >> ... > >> > >> Then should we have something along the lines of: > >> ... > >> $ git diff > >> diff --git a/gcc/tree-loop-distribution.c b/gcc/tree-loop-distribution.c > >> index 6fe59cd56855..9a211d30cd7e 100644 > >> --- a/gcc/tree-loop-distribution.c > >> +++ b/gcc/tree-loop-distribution.c > >> @@ -3683,7 +3683,11 @@ loop_distribution::transform_reduction_loop > >> && TYPE_PRECISION (ptr_type_node) >= 32) > >> || (TYPE_OVERFLOW_UNDEFINED (reduction_var_type) > >> && TYPE_PRECISION (reduction_var_type) <= > >> TYPE_PRECISION (sizetype))) > >> - && builtin_decl_implicit (BUILT_IN_STRLEN)) > >> + && builtin_decl_implicit (BUILT_IN_STRLEN) > >> + && flag_tree_loop_distribute_patterns) > >> generate_strlen_builtin (loop, reduction_var, load_iv.base, > >> reduction_iv.base, loc); > >> else if (direct_optab_handler (rawmemchr_optab, TYPE_MODE > >> (load_type)) > >> ... > >> ? > >> > >> Or is the comment no longer valid? > > > > It is still valid - and yes, I think we need to guard it with this flag > > but please do it in the caller to transform_reduction_loop. > > Done. > > Ok for trunk? OK. > Thanks, > - Tom