From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 89B0FC2D0A8 for ; Mon, 28 Sep 2020 13:23:03 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 05EB820774 for ; Mon, 28 Sep 2020 13:23:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="wg7ZKCnj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 05EB820774 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Wa7Y+CUJT91KSe0Eptt9E42Kt2/hAsxcKmmOCawWWns=; b=wg7ZKCnjcoPD88LDGiub3AYV6 TsLDBnVITVu3g1tlJa1Ui/wvtyZL/XTKWUGUqP2sj1KzBRwLo8yhe/fTmLCnTAA6jJ/CuoeA0AW+M LPtvZX6CZ+CewcYIOcWPnPpT4goUSEPazMpHaipMa/KozBO5+hJZiRn6GJvDVAhHIOTZukXz7kozO EznQKQCFsV3jHiynCUu65lnDo5OUkFWx4teAu0e4SyVSbHE9/xPdpqM7m3r8XlYncZSgL2T3NPfVy QqtpH+RYLAjUljq6MiyGm4A4HKNrCGLC5WONqIP3F8jDLb6JDnHZ1P7RkAybxseYg3Eegwp8mUPRo Ej4W/sOiQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kMt5s-0004zR-NI; Mon, 28 Sep 2020 13:21:28 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kMt5q-0004yj-Ey for linux-arm-kernel@lists.infradead.org; Mon, 28 Sep 2020 13:21:27 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6CA581063; Mon, 28 Sep 2020 06:21:22 -0700 (PDT) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6F6F73F73B; Mon, 28 Sep 2020 06:21:20 -0700 (PDT) Date: Mon, 28 Sep 2020 14:21:17 +0100 From: Dave Martin To: Andre Przywara Subject: Re: [PATCH 5/5] perf: arm_spe: Decode SVE events Message-ID: <20200928132114.GF6642@arm.com> References: <20200922101225.183554-1-andre.przywara@arm.com> <20200922101225.183554-6-andre.przywara@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200922101225.183554-6-andre.przywara@arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200928_092126_616358_8463EB4F X-CRM114-Status: GOOD ( 28.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Suzuki K Poulose , Peter Zijlstra , Catalin Marinas , Jiri Olsa , linux-kernel@vger.kernel.org, Arnaldo Carvalho de Melo , Alexander Shishkin , Ingo Molnar , James Clark , Leo Yan , Namhyung Kim , Will Deacon , Tan Xiaojun , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Sep 22, 2020 at 11:12:25AM +0100, Andre Przywara wrote: > The Scalable Vector Extension (SVE) is an ARMv8 architecture extension > that introduces very long vector operations (up to 2048 bits). (8192, in fact, though don't expect to see that on real hardware any time soon... qemu and the Arm fast model can do it, though.) > The SPE profiling feature can tag SVE instructions with additional > properties like predication or the effective vector length. > > Decode the new operation type bits in the SPE decoder to allow the perf > tool to correctly report about SVE instructions. I don't know anything about SPE, so just commenting on a few minor things that catch my eye here. > Signed-off-by: Andre Przywara > --- > .../arm-spe-decoder/arm-spe-pkt-decoder.c | 48 ++++++++++++++++++- > 1 file changed, 47 insertions(+), 1 deletion(-) > > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c > index a033f34846a6..f0c369259554 100644 > --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c > @@ -372,8 +372,35 @@ int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf, > } > case ARM_SPE_OP_TYPE: > switch (idx) { > - case 0: return snprintf(buf, buf_len, "%s", payload & 0x1 ? > + case 0: { > + size_t blen = buf_len; > + > + if ((payload & 0x89) == 0x08) { > + ret = snprintf(buf, buf_len, "SVE"); > + buf += ret; > + blen -= ret; (Nit: can ret be < 0 ? I've never been 100% clear on this myself for the s*printf() family -- if this assumption is widespread in perf tool a lready that I guess just go with the flow.) I wonder if this snprintf+increment+decrement sequence could be wrapped up as a helper, rather than having to be repeated all over the place. > + if (payload & 0x2) > + ret = snprintf(buf, buf_len, " FP"); > + else > + ret = snprintf(buf, buf_len, " INT"); > + buf += ret; > + blen -= ret; > + if (payload & 0x4) { > + ret = snprintf(buf, buf_len, " PRED"); > + buf += ret; > + blen -= ret; > + } > + /* Bits [7..4] encode the vector length */ > + ret = snprintf(buf, buf_len, " EVLEN%d", > + 32 << ((payload >> 4) & 0x7)); Isn't this just extracting 3 bits (0x7)? And what unit are we aiming for here: is it the number of bytes per vector, or something else? I'm confused by the fact that this will go up in steps of 32, which doesn't seem to match up to the architecure. I notice that bit 7 has to be zero to get into this if() though. > + buf += ret; > + blen -= ret; > + return buf_len - blen; > + } > + > + return snprintf(buf, buf_len, "%s", payload & 0x1 ? > "COND-SELECT" : "INSN-OTHER"); > + } > case 1: { > size_t blen = buf_len; > > @@ -403,6 +430,25 @@ int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf, > ret = snprintf(buf, buf_len, " NV-SYSREG"); > buf += ret; > blen -= ret; > + } else if ((payload & 0x0a) == 0x08) { > + ret = snprintf(buf, buf_len, " SVE"); > + buf += ret; > + blen -= ret; > + if (payload & 0x4) { > + ret = snprintf(buf, buf_len, " PRED"); > + buf += ret; > + blen -= ret; > + } > + if (payload & 0x80) { > + ret = snprintf(buf, buf_len, " SG"); > + buf += ret; > + blen -= ret; > + } > + /* Bits [7..4] encode the vector length */ > + ret = snprintf(buf, buf_len, " EVLEN%d", > + 32 << ((payload >> 4) & 0x7)); Same comment as above. Maybe have a common helper for decoding the vector length bits so it can be fixed in a single place? > + buf += ret; > + blen -= ret; > } else if (payload & 0x4) { > ret = snprintf(buf, buf_len, " SIMD-FP"); > buf += ret; Cheers ---Dave _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel