From patchwork Wed Sep 21 07:13:52 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Pinski X-Patchwork-Id: 672610 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3sf9pr49Rgz9ryv for ; Wed, 21 Sep 2016 17:14:12 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=JzpB1qIs; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:from:date:message-id:subject:to:content-type; q= dns; s=default; b=hMW4t82KQRRIpdZBjC8geR7ojkHTl6E9CvxkHj9E1GFOyc qU5aHbxWUI3g0iLH5loyDYJ+0HFb3heS34jnHAcRQPA3d5TR1wPBdQGn9S3/xJb4 7XRuEE6Yuzd2FfCPr2q7TJf+Jd95M2IknsbyMYIPlGrFgR1NnaIH4RFZ1oc10= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:from:date:message-id:subject:to:content-type; s= default; bh=XRMFC5NZRWMd7CEODlhb+/DazGg=; b=JzpB1qIsBLZGvpl3nnui C1HDR/JZ22F+7hxvx2/YwE0jxP/84wTQnK8vApYHAmVasB0RXNLe3g6766zQJIh+ oWoy9peRCSTWHPsDxLX0D4mhsjXb6c2fBse4hwdJdQTo+gpRYHcwEQCREN96fbaG 1b7Z42nA++RANGEDYSwHAYU= Received: (qmail 118880 invoked by alias); 21 Sep 2016 07:13:59 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 118780 invoked by uid 89); 21 Sep 2016 07:13:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2357, kick X-HELO: mail-lf0-f43.google.com Received: from mail-lf0-f43.google.com (HELO mail-lf0-f43.google.com) (209.85.215.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 21 Sep 2016 07:13:56 +0000 Received: by mail-lf0-f43.google.com with SMTP id g62so32484315lfe.3 for ; Wed, 21 Sep 2016 00:13:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=x4WELtCqAyUlvfNaL0TnPwvIRDZDSD/9UqIlg2rhXAU=; b=ABbeQXHhNxI9evbE8iC9AZNop9v9LLSEcp1L9c8I+8mnBqgui75aIn8ymnfvVsKwS6 IHe7+YjIUJx8+Rbwx1y++o3I7lRslahp7jQkLYEJajvTN3HuIZ/K5kxnE51TgMQMMsHP OE6b4noIpHQb2AAgrNKjCJLB9BBMRDDoKJxqLEMZao6qIqUeAvNpSYGlMB/0fnTreh6c xLvsRo04hoPV27DvMrQnXjpmFYAbIdMcMZ+mDpxGWHsrqaHM3upKYqSPNyX0ZIb47JZj +zXIRuznLsHXR/Ybv7U/RPD53ZQ48fdcXjKtYXcOFcYnF8orHo01YjsKlXmWeWIMfIqM fznQ== X-Gm-Message-State: AE9vXwPz5G8o/wzT2J0EXwo6bsEdkPcKXwakzwMKl13Jwv0Fy2Ph/ygXP2iypR+IPWahXOJmc6i1NnwHyP8icw== X-Received: by 10.46.0.75 with SMTP id 72mr13696196lja.50.1474442033648; Wed, 21 Sep 2016 00:13:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.166.76 with HTTP; Wed, 21 Sep 2016 00:13:52 -0700 (PDT) From: Andrew Pinski Date: Wed, 21 Sep 2016 15:13:52 +0800 Message-ID: Subject: [PATCH] (PR 65950) Improve predicate for exit(0); To: GCC Patches X-IsSubscribed: yes Hi, While looking through bug reports, I noticed someone had reported that LTO caused the vectorizer not to kick in. Originally it was not obvious why it would change the behavior since this was a simple program with nothing out of the ordinary. Well it turned out paths leading to the exit(0); at the end of main was being marked as cold and in the LTO case the funciton (which had loop which should have been vectorized) was considered local and being marked as cold as it was only called now from the path leading to the exit(0); Since exit(0); is considered a normal exit path, there is no reason to mark it as being as a cold path; let the other predicate handle it. So this patch changes the predicate for exit(0) not to mark the paths leading up to that function call as being cold. Note this patch only disables that when the argument is a literal zero so if we a PHI node which contains the exit value, we still cause those paths to be considered cold; this will be for another patch. OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions. Also tested it with SPEC CPU 2006 with no performance regressions. Thanks, Andrew Pinski ChangeLog: * predict.c (is_exit_with_zero_arg): New function. (tree_bb_level_predictions): Don't consider paths leading to exit(0) as nottaken. Index: gcc/predict.c =================================================================== --- gcc/predict.c (revision 240299) +++ gcc/predict.c (working copy) @@ -2513,6 +2513,21 @@ } } +/* Returns TRUE if the STMT is exit(0) like statement. */ + +static bool +is_exit_with_zero_arg (const gimple *stmt) +{ + /* This is not exit, _exit or _Exit. */ + if (!gimple_call_builtin_p (stmt, BUILT_IN_EXIT) + && !gimple_call_builtin_p (stmt, BUILT_IN__EXIT) + && !gimple_call_builtin_p (stmt, BUILT_IN__EXIT2)) + return false; + + /* Argument is an interger zero. */ + return integer_zerop (gimple_call_arg (stmt, 0)); +} + /* Try to guess whether the value of return means error code. */ static enum br_predictor @@ -2639,7 +2654,9 @@ if (is_gimple_call (stmt)) { - if (gimple_call_noreturn_p (stmt) && has_return_edges) + if (gimple_call_noreturn_p (stmt) + && has_return_edges + && !is_exit_with_zero_arg (stmt)) predict_paths_leading_to (bb, PRED_NORETURN, NOT_TAKEN); decl = gimple_call_fndecl (stmt);