From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id 884823838000 for ; Mon, 26 Apr 2021 16:57:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 884823838000 Received: by mail-pj1-x1032.google.com with SMTP id h14-20020a17090aea8eb02901553e1cc649so3440806pjz.0 for ; Mon, 26 Apr 2021 09:57:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e1L6pBEqEqf9yzzLdCbXUs35pRV++EsUY5L3ndRXmVk=; b=h0ZeDWLhhDTyHdLvIpDPiLH5F9NP0kjloMQH8MQpwDpv/O9+N4Ew+DiGiJNpY+Lquq W7fkORRKCBnmMpucxWh6Uc10iAq1b9xaBOf2ZU/5iu2130Ymbswh8ztgXJh4YrT69xmg GLoC9FU8pOxsOs46TLo5piPsxTw9YGJCtaH5yDQdWM2PeT8ytXtLouxD71gpXKJfbUy4 nsb7kXEA0IpyFHqHp5yr0K0fIy46tXPsDv260zCXlXv+svecRoG2yMadXG4FQ6HGGl14 SHTeneR7oY+SM7YobvArHwavn5WWOqe8Q+JGZ2BcSrprEAsYek7Ae+q6ph7ZXAJCRjSH Sr1A== X-Gm-Message-State: AOAM532eyiKK2pn4+Y6a6gLEGbbCXgM2kGwsejuUPGrWwoYITkP3RPoa sXFqXhJzP6XsvKGAntoMxkBBo8O09awD0gKmtNZ7zg== X-Google-Smtp-Source: ABdhPJztVJWMfFXqrE7XIVoHVXaiT4l629VyUhIdrkIPqetk3C33t0uZMh7/YaPR4vwVJWueD3gwJbJnUdHbdygP978= X-Received: by 2002:a17:90b:1208:: with SMTP id gl8mr22555417pjb.12.1619456246386; Mon, 26 Apr 2021 09:57:26 -0700 (PDT) MIME-Version: 1.0 References: <20210423165449.GC56452@kam.mff.cuni.cz> <20210423171611.GA82007@kam.mff.cuni.cz> <20210423192834.GA1949@kam.mff.cuni.cz> <20210425190754.GA88857@kam.mff.cuni.cz> <87a6plulkz.fsf@linux.intel.com> In-Reply-To: <87a6plulkz.fsf@linux.intel.com> From: Xinliang David Li Date: Mon, 26 Apr 2021 09:57:15 -0700 Message-ID: Subject: Re: State of AutoFDO in GCC To: Andi Kleen Cc: Jan Hubicka , "gcc@gcc.gnu.org" , Wei Mi , Eugene Rozenfeld X-Spam-Status: No, score=-17.0 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 16:57:29 -0000 On Mon, Apr 26, 2021 at 8:12 AM Andi Kleen wrote: > Jan Hubicka writes: > > > > Is there a way to get this working w/o using older perf? > > It's usually rather simple to fix up autofdo for new perf. > I did it before here > > https://github.com/andikleen/autofdo/commits/perf4-3 > > I think it would work always if it just ignored unknown records > (which is quite possible). perf adds new records now and then, > but they can be usually ignored by old tools. > Only the assert happy coding style in autofdo prevents it. > > BTW longer term my feeling is autofdo should be replaced with something > like https://lists.llvm.org/pipermail/llvm-dev/2020-August/144101.html > I think that would fix most of the weirdnesses in the current autofdo > implementation. > There are multiple directional changes in this new tool: 1) it uses perf-script trace output (in text) as input profile data; 2) it uses pseudo probe like instrumentation FDO to do profile matching; 3) it supports full profile context sensitivity (not just from inline stacks). #1 is most relevant to this discussion -- using text format reduces the pain introduced by perf binary format change. David > > -Andi >