From patchwork Wed Oct 7 16:11:26 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: max X-Patchwork-Id: 527359 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 17CB81402B0 for ; Thu, 8 Oct 2015 03:12:02 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=juLMBpVI; 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:to:cc :from:subject:message-id:date:mime-version:content-type; q=dns; s=default; b=vLuPCPbgUJ8rR7r7Luk7GdIXViyfcKYdbL26fStdF+IpUn6jUf eTQvC695gAiv+1bvy3bcGsDVujC5x8Fm2s17ZEdPBa8NOr0DLzO5anDFHDgB/4jE j+9E0dXCY6ksLQd99m1xRa2vLmu/SYoC9DGSgwJcjRLmydZyN9YMWWYSQ= 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:to:cc :from:subject:message-id:date:mime-version:content-type; s= default; bh=7N0weiyPmhf2x05dO9WgvTmWr5Q=; b=juLMBpVI3Awg0Th3hRbL svmCP4IpW1b4QwKVFZgK6VGThPcouEnyonvPjpSAOp3GKPd75IzGTdTuxNt2Y/y2 4+1dd7IeQUvqxNdHNpujgo36O8X3XWtcpAuXB6mH0+/V3zlYugrMLcjUqdRTOPbM cBNXE1aCGiP43FzbAdIEV2Y= Received: (qmail 78801 invoked by alias); 7 Oct 2015 16:11:38 -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 78721 invoked by uid 89); 7 Oct 2015 16:11:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL, BAYES_00, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_PASS, T_HDRS_LCASE, T_MANY_HDRS_LCASE, T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mailout2.w1.samsung.com Received: from mailout2.w1.samsung.com (HELO mailout2.w1.samsung.com) (210.118.77.12) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 07 Oct 2015 16:11:34 +0000 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout2.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NVU00EYPYB5K160@mailout2.w1.samsung.com> for gcc-patches@gcc.gnu.org; Wed, 07 Oct 2015 17:11:29 +0100 (BST) Received: from eusync2.samsung.com ( [203.254.199.212]) by eucpsbgm1.samsung.com (EUCPMTA) with SMTP id E0.00.04846.13445165; Wed, 7 Oct 2015 17:11:29 +0100 (BST) Received: from [106.109.128.167] by eusync2.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0NVU00BH5YB4YZC0@eusync2.samsung.com>; Wed, 07 Oct 2015 17:11:29 +0100 (BST) To: GCC Patches Cc: Vyacheslav Barinov , Nikolay Bozhenov , Slava Garbuzov From: Maxim Ostapenko Subject: [RFC, PATCH] Disable -fprofile-use related optimizations if corresponding .gcda file not found. Message-id: <5615442E.9090200@partner.samsung.com> Date: Wed, 07 Oct 2015 19:11:26 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-version: 1.0 Content-type: multipart/mixed; boundary=------------070805080601010604040409 X-IsSubscribed: yes Hi, when testing OpenSSL performance, I found out that sometimes PGO-built binaries can actually introduce performance regressions. We could identify affected object files and disable PGO for them by simply removing corresponding .gcda file. However, even if profile data is not presented, GCC doesn't switch back -fprofile-use dependent optimizations (e.g. -fbranch-probabilities, -fvpt, etc). This may also lead to performance degradations. The issue had already raised quite time ago (https://gcc.gnu.org/ml/gcc-patches/2009-09/msg02119.html), but for some reasons wasn't discussed. Here a draft patch that disables -fprofile-use related optimizations if profile data wasn't found (perhaps it makes sense to introduce a special switch for this?). Does this look reasonable? Thanks, -Maxim gcc/ChangeLog: 2015-10-07 Maxim Ostapenko * coverage.c (disable_profile_use_flags): New function. (read_counts_file): Call it if corresponding .gcda file wasn't found. diff --git a/gcc/coverage.c b/gcc/coverage.c index 4c06fa4..37e16b7 100644 --- a/gcc/coverage.c +++ b/gcc/coverage.c @@ -134,6 +134,7 @@ static bool coverage_obj_init (void); static vec *coverage_obj_fn (vec *, tree, struct coverage_data const *); static void coverage_obj_finish (vec *); +static void disable_profile_use_flags (void); /* Return the type node for gcov_type. */ @@ -190,7 +191,10 @@ read_counts_file (void) unsigned cfg_checksum = 0; if (!gcov_open (da_file_name, 1)) - return; + { + disable_profile_use_flags (); + return; + } if (!gcov_magic (gcov_read_unsigned (), GCOV_DATA_MAGIC)) { @@ -1219,4 +1223,14 @@ coverage_finish (void) da_file_name = NULL; } +/* Reset flags if a .gcda file is not found. */ +static void +disable_profile_use_flags (void) +{ + flag_branch_probabilities = flag_profile_values = flag_unroll_loops = false; + flag_value_profile_transformations + = flag_tree_loop_distribute_patterns = false; + flag_rename_registers = flag_peel_loops = false; + flag_profile_reorder_functions = flag_tracer = false; +} + #include "gt-coverage.h"