From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-376439-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 6720 invoked by alias); 29 Aug 2014 17:11:10 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 6708 invoked by uid 89); 29 Aug 2014 17:11:09 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mail-qg0-f45.google.com
Received: from mail-qg0-f45.google.com (HELO mail-qg0-f45.google.com) (209.85.192.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 29 Aug 2014 17:11:08 +0000
Received: by mail-qg0-f45.google.com with SMTP id e89so2542722qgf.18        for <gcc-patches@gcc.gnu.org>; Fri, 29 Aug 2014 10:11:06 -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:in-reply-to:references:date         :message-id:subject:from:to:cc:content-type;        bh=2fd7be63o3Jr+vFYEwEEHejcjGITYohUNXWDXzmPeSk=;        b=c7EkNCqYJtGxfakNeKfV+YoSxy5z8otkVZzsVRa3ZqPM9ZJibbkPcYSc18HWB1Qwg8         Hiasr8/JKPBl0JDZzvKvmGSTy62spjSkjh6IGjt+MvAo7z4OjueMsmCWbyrxN7r5NqGm         f7wcgFewUc9DybbXnsS6fu/4C8i9LYBX9fd74ot+YzpvWB9Bz+Zsnnw0rcZAYoeA2B6N         wUEf6VhTvHTQmxYG03C1HVbbaQrbvN5OwZjuUWVRVMFCM/72llyx8ZGfwbkrfM4NiFSo         Ak90PZgy/4dKWSdNwqUG++BYwszV2HdASCOBA2fpuX9lCHoqXEBO/rvNk7rdvzTtNNiZ         ghbQ==
X-Gm-Message-State: ALoCoQnpU0nz3mlbI/4zQkbR+Q+kJvuTSwHGiNEPOwVYfPwLJ9uOZ0J0ZZDSEU03bt2OSHEBIelo
MIME-Version: 1.0
X-Received: by 10.140.109.116 with SMTP id k107mr271285qgf.36.1409332266101; Fri, 29 Aug 2014 10:11:06 -0700 (PDT)
Received: by 10.140.107.73 with HTTP; Fri, 29 Aug 2014 10:11:06 -0700 (PDT)
In-Reply-To: <CA+4CFy5qHHuXhWhFjTzQUmvDs50QiQCitjsbhTCO5V-cha6Qnw@mail.gmail.com>
References: <CA+4CFy6AUJ6UL_RjYBhjWjQA+GBxoac4yh44=UkKBvJAtAekFA@mail.gmail.com>	<CAHACq4rjjf9yWAe1qtyqCpaoUfu8ESQ=K9CvO=YtXo3Xo4VGJw@mail.gmail.com>	<CA+4CFy6ZW2__5aR86Uo9gV+fbgNQb+_P2dPXeEy1iCTVn5kmUA@mail.gmail.com>	<CA+4CFy5qHHuXhWhFjTzQUmvDs50QiQCitjsbhTCO5V-cha6Qnw@mail.gmail.com>
Date: Fri, 29 Aug 2014 17:11:00 -0000
Message-ID: <CAHACq4q-iSnDaiqViYGSrfiokxTRHNoSGsfm06bLquh44G=Tpw@mail.gmail.com>
Subject: Re: [GOOGLE, AUTOFDO] Assign different discriminators to calls with the same lineno
From: Cary Coutant <ccoutant@google.com>
To: Wei Mi <wmi@google.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>, David Li <davidxl@google.com>, 	Dehao Chen <dehao@google.com>
Content-Type: text/plain; charset=UTF-8
X-IsSubscribed: yes
X-SW-Source: 2014-08/txt/msg02648.txt.bz2

> To avoid the unused new discriminator value, I added a map
> "found_call_this_line" to track whether a call is the first call in a
> source line seen when assigning discriminators. For the first call in
> a source line, its discriminator is 0. For the following calls in the
> same source line, a new discriminator will be used everytime. The new
> patch is attached. Internal perf test and regression test are ok. Is
> it ok for google-4_9?

This seems overly complex to me. I'd think all you need to do is add a
bit to locus_discrim_map (stealing a bit from discriminator ought to
be fine) that indicates whether the next call should increment the
discriminator or not. Something like this:

increase_discriminator_for_locus (location_t locus, bool return_next)
{
  ...
  if (return_next || (*slot)->needs_increment)
    {
      (*slot)->discriminator++;
      (*slot)->needs_increment = false;
    }
  else
    (*slot)->needs_increment = true;
  return (*slot)->discriminator;
}

-cary