From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80351 invoked by alias); 13 Nov 2018 18:37:34 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 80339 invoked by uid 89); 13 Nov 2018 18:37:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2414, vartracking, var-tracking X-HELO: mail-wr1-f68.google.com Received: from mail-wr1-f68.google.com (HELO mail-wr1-f68.google.com) (209.85.221.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 13 Nov 2018 18:37:32 +0000 Received: by mail-wr1-f68.google.com with SMTP id y3-v6so14449604wrh.10 for ; Tue, 13 Nov 2018 10:37:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:cc:from:message-id; bh=JeYDa9PYFjjgFuGBX3ZURbMw7nVJz6c74VodziEu5kA=; b=tAu0kWzPI25iP0hKhNeVIQhxofGosScf5gi6iZlUgSaQNMbWwEnTZvB1hgZJrdJX0F 243aoJZPdFleaQXGVv/EfFy0esfG021OhZ7i/M7tBUyFZnY6JEgIxuqqBeDpTZKEZ92Y 1MqU3KqHn3A0VYZnXTG2KLdgYOpO+nJl/g8nndb1KJOiWIQjeyiiHGZqWzAYKEy6Ml/J QqwSn0GPj6FTmY7Sp6wAmMnnixc5bKd8YjC0Zf76pQBViKGUN+zl3oJDNmOWfLYKg+TE fapIu3IijGWmISbc2tWl7/S2lqX7CiJvfq16Z3DK7kW18G3XZdXV3dYzqqG7/MNSReIP +97Q== Return-Path: Received: from [192.168.178.32] (x5f733f51.dyn.telefonica.de. [95.115.63.81]) by smtp.gmail.com with ESMTPSA id a1-v6sm12462226wrs.62.2018.11.13.10.37.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Nov 2018 10:37:29 -0800 (PST) Date: Tue, 13 Nov 2018 18:37:00 -0000 User-Agent: K-9 Mail for Android In-Reply-To: <20181113180915.skcqes73spiruooa@two.firstfloor.org> References: <20181104063235.6914-1-andi@firstfloor.org> <20181104063235.6914-2-andi@firstfloor.org> <20181109181837.GB6218@tassilo.jf.intel.com> <20181112031610.GF6218@tassilo.jf.intel.com> <20181113180915.skcqes73spiruooa@two.firstfloor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH 2/3] Add a pass to automatically add ptwrite instrumentation To: Andi Kleen CC: Andi Kleen ,GCC Patches From: Richard Biener Message-ID: <09B38DAB-F70B-4DFB-8BA2-4F5774A11753@gmail.com> X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg01132.txt.bz2 On November 13, 2018 7:09:15 PM GMT+01:00, Andi Kleen = wrote: >On Tue, Nov 13, 2018 at 09:03:52AM +0100, Richard Biener wrote: >> > I even had an earlier version of this that instrumented >> > assembler output of the compiler with PTWRITE in a separate script, >> > and it worked fine too. >>=20 >> Apart from eventually messing up branch range restrictions I guess ;) > >You mean for LOOP? For everything else the assembler handles it I >believe. > >> Did you gather any statistics on how many ptwrite instructions >> that are generated by your patch are not covered by any >> location range & expr?=20=20 > >Need to look into that. Any suggestions how to do it in the compiler? I guess you need to do that in a dwarf decoder somehow.=20 >I had some decode failures with the perf dwarf decoder, >but I was usually blaming them on perf dwarf limitations.=20 > >> I assume ptwrite is writing from register >> input only so you probably should avoid instrumenting writes >> of constants (will require an extra register)? > >Hmm, I think those are needed unfortunately because someone >might want to trace every update of of something. With branch >tracing it could be recreated theoretically but would=20 >be a lot more work for the decoder. > >> How does the .text size behave say for cc1 when you enable >> the various granularities of instrumentation? How many >> ptwrite instructions are there per 100 regular instructions? > >With locals tracing (worst case) I see ~23% of all instructions >in cc1 be PTWRITE. Binary is ~27% bigger. OK, I suppose it will get better when addressing some of my review comments= .=20 >> Can we get an updated patch based on my review? > >Yes, working on it, also addressing Martin's comments. Hopefully soon. >>=20 >> I still think we should eventually move the pass later > >It's after pass_sanopt now. > >> avoid instrumenting places we'll not have any meaningful locations >> in the debug info - if only to reduce required trace bandwith. > >Can you suggest how to check that? I'd look at doing the instrumentation after var-tracking has run - that is = what computes the locations in the end. That means instrumenting on late RT= L after register allocation (and eventually with branch range restrictions = in place). Basically you'd instrument at the same time as generating debug = info. Richard.=20 >-Andi