2012-04-13 03:08:20 +02:00
|
|
|
// -*- mode: C++; c-file-style: "cc-mode" -*-
|
2006-08-26 13:35:28 +02:00
|
|
|
//*************************************************************************
|
|
|
|
|
// DESCRIPTION: Verilator: Collect and print statistics
|
|
|
|
|
//
|
2019-11-08 04:33:59 +01:00
|
|
|
// Code available from: https://verilator.org
|
2006-08-26 13:35:28 +02:00
|
|
|
//
|
|
|
|
|
//*************************************************************************
|
|
|
|
|
//
|
2023-01-01 16:18:39 +01:00
|
|
|
// Copyright 2005-2023 by Wilson Snyder. This program is free software; you
|
2020-03-21 16:24:24 +01:00
|
|
|
// can redistribute it and/or modify it under the terms of either the GNU
|
2009-05-04 23:07:57 +02:00
|
|
|
// Lesser General Public License Version 3 or the Perl Artistic License
|
|
|
|
|
// Version 2.0.
|
2020-03-21 16:24:24 +01:00
|
|
|
// SPDX-License-Identifier: LGPL-3.0-only OR Artistic-2.0
|
2006-08-26 13:35:28 +02:00
|
|
|
//
|
|
|
|
|
//*************************************************************************
|
2019-10-05 02:17:11 +02:00
|
|
|
|
2023-10-18 04:50:27 +02:00
|
|
|
#include "V3PchAstMT.h"
|
|
|
|
|
|
2023-10-18 12:37:46 +02:00
|
|
|
#include "V3Stats.h"
|
|
|
|
|
|
2018-10-14 19:43:24 +02:00
|
|
|
#include <iomanip>
|
|
|
|
|
#include <map>
|
|
|
|
|
|
2022-09-18 21:53:42 +02:00
|
|
|
VL_DEFINE_DEBUG_FUNCTIONS;
|
|
|
|
|
|
2006-08-26 13:35:28 +02:00
|
|
|
//######################################################################
|
|
|
|
|
// Stats class functions
|
|
|
|
|
|
2023-03-18 00:58:53 +01:00
|
|
|
class StatsVisitor final : public VNVisitorConst {
|
Simplify and fix code stats
V3Stats for "fast" code have bit-rotted a little and is causing some
problems with tests that rely on stats outputs. The problem is that not
all code is necessarily reachable from eval() any more (due to the
complexity of some the features added over the past few years), so it
might miss some things, as for measuring the "fast" code, it is trying
to trace the execution paths via calls, starting from eval(). It also
appears the fast code can also contain calls to slow code in some
circumstances.
To avoid all that, removed trying to trace dynamic execution, and simply
report the static node counts, which is enough for testing.
Similarly, the variable counts are somewhat dubious, as they don't
include all data types, or all instances of a module in some stages.
Removing these as they are not widely used nor dependable. More specific
stats can be added if required and can be well defined.
2023-10-21 15:45:30 +02:00
|
|
|
struct Counters final {
|
|
|
|
|
// Nodes of given type
|
|
|
|
|
uint64_t m_statTypeCount[VNType::_ENUM_END];
|
|
|
|
|
// Nodes of given type with given type immediate child
|
|
|
|
|
uint64_t m_statAbove[VNType::_ENUM_END][VNType::_ENUM_END];
|
|
|
|
|
// Prediction of given type
|
|
|
|
|
uint64_t m_statPred[VBranchPred::_ENUM_END];
|
|
|
|
|
};
|
2014-12-20 14:28:31 +01:00
|
|
|
|
2006-08-26 13:35:28 +02:00
|
|
|
// STATE
|
Simplify and fix code stats
V3Stats for "fast" code have bit-rotted a little and is causing some
problems with tests that rely on stats outputs. The problem is that not
all code is necessarily reachable from eval() any more (due to the
complexity of some the features added over the past few years), so it
might miss some things, as for measuring the "fast" code, it is trying
to trace the execution paths via calls, starting from eval(). It also
appears the fast code can also contain calls to slow code in some
circumstances.
To avoid all that, removed trying to trace dynamic execution, and simply
report the static node counts, which is enough for testing.
Similarly, the variable counts are somewhat dubious, as they don't
include all data types, or all instances of a module in some stages.
Removing these as they are not widely used nor dependable. More specific
stats can be added if required and can be well defined.
2023-10-21 15:45:30 +02:00
|
|
|
const bool m_fastOnly; // When true, consider only fast functions
|
|
|
|
|
const AstNodeExpr* m_parentExprp = nullptr; // Parent expression
|
|
|
|
|
Counters m_counters; // The actual counts we will display
|
|
|
|
|
Counters m_dumpster; // Alternate buffer to make discarding parts of the tree easier
|
|
|
|
|
Counters* m_accump; // The currently active accumulator
|
|
|
|
|
std::vector<uint64_t> m_statVarWidths; // Variables of given width
|
|
|
|
|
std::vector<std::map<const std::string, uint32_t>>
|
|
|
|
|
m_statVarWidthNames; // Var names of given width
|
2006-08-26 13:35:28 +02:00
|
|
|
|
|
|
|
|
// METHODS
|
Simplify and fix code stats
V3Stats for "fast" code have bit-rotted a little and is causing some
problems with tests that rely on stats outputs. The problem is that not
all code is necessarily reachable from eval() any more (due to the
complexity of some the features added over the past few years), so it
might miss some things, as for measuring the "fast" code, it is trying
to trace the execution paths via calls, starting from eval(). It also
appears the fast code can also contain calls to slow code in some
circumstances.
To avoid all that, removed trying to trace dynamic execution, and simply
report the static node counts, which is enough for testing.
Similarly, the variable counts are somewhat dubious, as they don't
include all data types, or all instances of a module in some stages.
Removing these as they are not widely used nor dependable. More specific
stats can be added if required and can be well defined.
2023-10-21 15:45:30 +02:00
|
|
|
void countThenIterateChildren(AstNode* nodep) {
|
|
|
|
|
++m_accump->m_statTypeCount[nodep->type()];
|
|
|
|
|
iterateChildrenConst(nodep);
|
2006-08-26 13:35:28 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// VISITORS
|
2022-09-16 12:22:11 +02:00
|
|
|
void visit(AstVar* nodep) override {
|
Simplify and fix code stats
V3Stats for "fast" code have bit-rotted a little and is causing some
problems with tests that rely on stats outputs. The problem is that not
all code is necessarily reachable from eval() any more (due to the
complexity of some the features added over the past few years), so it
might miss some things, as for measuring the "fast" code, it is trying
to trace the execution paths via calls, starting from eval(). It also
appears the fast code can also contain calls to slow code in some
circumstances.
To avoid all that, removed trying to trace dynamic execution, and simply
report the static node counts, which is enough for testing.
Similarly, the variable counts are somewhat dubious, as they don't
include all data types, or all instances of a module in some stages.
Removing these as they are not widely used nor dependable. More specific
stats can be added if required and can be well defined.
2023-10-21 15:45:30 +02:00
|
|
|
if (nodep->dtypep()) {
|
|
|
|
|
if (m_statVarWidths.size() <= static_cast<size_t>(nodep->width())) {
|
2020-04-14 04:51:35 +02:00
|
|
|
m_statVarWidths.resize(nodep->width() + 5);
|
Simplify and fix code stats
V3Stats for "fast" code have bit-rotted a little and is causing some
problems with tests that rely on stats outputs. The problem is that not
all code is necessarily reachable from eval() any more (due to the
complexity of some the features added over the past few years), so it
might miss some things, as for measuring the "fast" code, it is trying
to trace the execution paths via calls, starting from eval(). It also
appears the fast code can also contain calls to slow code in some
circumstances.
To avoid all that, removed trying to trace dynamic execution, and simply
report the static node counts, which is enough for testing.
Similarly, the variable counts are somewhat dubious, as they don't
include all data types, or all instances of a module in some stages.
Removing these as they are not widely used nor dependable. More specific
stats can be added if required and can be well defined.
2023-10-21 15:45:30 +02:00
|
|
|
if (v3Global.opt.statsVars()) { //
|
|
|
|
|
m_statVarWidthNames.resize(nodep->width() + 5);
|
|
|
|
|
}
|
2019-05-19 22:13:13 +02:00
|
|
|
}
|
2020-04-14 04:51:35 +02:00
|
|
|
++m_statVarWidths.at(nodep->width());
|
2019-05-19 22:13:13 +02:00
|
|
|
if (v3Global.opt.statsVars()) {
|
Simplify and fix code stats
V3Stats for "fast" code have bit-rotted a little and is causing some
problems with tests that rely on stats outputs. The problem is that not
all code is necessarily reachable from eval() any more (due to the
complexity of some the features added over the past few years), so it
might miss some things, as for measuring the "fast" code, it is trying
to trace the execution paths via calls, starting from eval(). It also
appears the fast code can also contain calls to slow code in some
circumstances.
To avoid all that, removed trying to trace dynamic execution, and simply
report the static node counts, which is enough for testing.
Similarly, the variable counts are somewhat dubious, as they don't
include all data types, or all instances of a module in some stages.
Removing these as they are not widely used nor dependable. More specific
stats can be added if required and can be well defined.
2023-10-21 15:45:30 +02:00
|
|
|
++m_statVarWidthNames.at(nodep->width())[nodep->prettyName()];
|
2019-05-19 22:13:13 +02:00
|
|
|
}
|
|
|
|
|
}
|
Simplify and fix code stats
V3Stats for "fast" code have bit-rotted a little and is causing some
problems with tests that rely on stats outputs. The problem is that not
all code is necessarily reachable from eval() any more (due to the
complexity of some the features added over the past few years), so it
might miss some things, as for measuring the "fast" code, it is trying
to trace the execution paths via calls, starting from eval(). It also
appears the fast code can also contain calls to slow code in some
circumstances.
To avoid all that, removed trying to trace dynamic execution, and simply
report the static node counts, which is enough for testing.
Similarly, the variable counts are somewhat dubious, as they don't
include all data types, or all instances of a module in some stages.
Removing these as they are not widely used nor dependable. More specific
stats can be added if required and can be well defined.
2023-10-21 15:45:30 +02:00
|
|
|
|
|
|
|
|
countThenIterateChildren(nodep);
|
2006-08-26 13:35:28 +02:00
|
|
|
}
|
Simplify and fix code stats
V3Stats for "fast" code have bit-rotted a little and is causing some
problems with tests that rely on stats outputs. The problem is that not
all code is necessarily reachable from eval() any more (due to the
complexity of some the features added over the past few years), so it
might miss some things, as for measuring the "fast" code, it is trying
to trace the execution paths via calls, starting from eval(). It also
appears the fast code can also contain calls to slow code in some
circumstances.
To avoid all that, removed trying to trace dynamic execution, and simply
report the static node counts, which is enough for testing.
Similarly, the variable counts are somewhat dubious, as they don't
include all data types, or all instances of a module in some stages.
Removing these as they are not widely used nor dependable. More specific
stats can be added if required and can be well defined.
2023-10-21 15:45:30 +02:00
|
|
|
|
|
|
|
|
void visit(AstNodeExpr* nodep) override {
|
|
|
|
|
// Count expression combinations
|
|
|
|
|
if (m_parentExprp) ++m_accump->m_statAbove[m_parentExprp->type()][nodep->type()];
|
|
|
|
|
VL_RESTORER(m_parentExprp);
|
|
|
|
|
m_parentExprp = nodep;
|
|
|
|
|
countThenIterateChildren(nodep);
|
2006-08-26 13:35:28 +02:00
|
|
|
}
|
Simplify and fix code stats
V3Stats for "fast" code have bit-rotted a little and is causing some
problems with tests that rely on stats outputs. The problem is that not
all code is necessarily reachable from eval() any more (due to the
complexity of some the features added over the past few years), so it
might miss some things, as for measuring the "fast" code, it is trying
to trace the execution paths via calls, starting from eval(). It also
appears the fast code can also contain calls to slow code in some
circumstances.
To avoid all that, removed trying to trace dynamic execution, and simply
report the static node counts, which is enough for testing.
Similarly, the variable counts are somewhat dubious, as they don't
include all data types, or all instances of a module in some stages.
Removing these as they are not widely used nor dependable. More specific
stats can be added if required and can be well defined.
2023-10-21 15:45:30 +02:00
|
|
|
|
2022-09-16 12:22:11 +02:00
|
|
|
void visit(AstNodeIf* nodep) override {
|
2019-05-19 22:13:13 +02:00
|
|
|
// Track prediction
|
Simplify and fix code stats
V3Stats for "fast" code have bit-rotted a little and is causing some
problems with tests that rely on stats outputs. The problem is that not
all code is necessarily reachable from eval() any more (due to the
complexity of some the features added over the past few years), so it
might miss some things, as for measuring the "fast" code, it is trying
to trace the execution paths via calls, starting from eval(). It also
appears the fast code can also contain calls to slow code in some
circumstances.
To avoid all that, removed trying to trace dynamic execution, and simply
report the static node counts, which is enough for testing.
Similarly, the variable counts are somewhat dubious, as they don't
include all data types, or all instances of a module in some stages.
Removing these as they are not widely used nor dependable. More specific
stats can be added if required and can be well defined.
2023-10-21 15:45:30 +02:00
|
|
|
++m_accump->m_statPred[nodep->branchPred()];
|
|
|
|
|
countThenIterateChildren(nodep);
|
2006-08-26 13:35:28 +02:00
|
|
|
}
|
|
|
|
|
|
2022-09-16 12:22:11 +02:00
|
|
|
void visit(AstCFunc* nodep) override {
|
Simplify and fix code stats
V3Stats for "fast" code have bit-rotted a little and is causing some
problems with tests that rely on stats outputs. The problem is that not
all code is necessarily reachable from eval() any more (due to the
complexity of some the features added over the past few years), so it
might miss some things, as for measuring the "fast" code, it is trying
to trace the execution paths via calls, starting from eval(). It also
appears the fast code can also contain calls to slow code in some
circumstances.
To avoid all that, removed trying to trace dynamic execution, and simply
report the static node counts, which is enough for testing.
Similarly, the variable counts are somewhat dubious, as they don't
include all data types, or all instances of a module in some stages.
Removing these as they are not widely used nor dependable. More specific
stats can be added if required and can be well defined.
2023-10-21 15:45:30 +02:00
|
|
|
VL_RESTORER(m_accump);
|
|
|
|
|
if (m_fastOnly && !nodep->slow()) m_accump = &m_counters;
|
|
|
|
|
countThenIterateChildren(nodep);
|
2017-12-01 00:53:57 +01:00
|
|
|
}
|
2020-04-14 04:51:35 +02:00
|
|
|
|
Simplify and fix code stats
V3Stats for "fast" code have bit-rotted a little and is causing some
problems with tests that rely on stats outputs. The problem is that not
all code is necessarily reachable from eval() any more (due to the
complexity of some the features added over the past few years), so it
might miss some things, as for measuring the "fast" code, it is trying
to trace the execution paths via calls, starting from eval(). It also
appears the fast code can also contain calls to slow code in some
circumstances.
To avoid all that, removed trying to trace dynamic execution, and simply
report the static node counts, which is enough for testing.
Similarly, the variable counts are somewhat dubious, as they don't
include all data types, or all instances of a module in some stages.
Removing these as they are not widely used nor dependable. More specific
stats can be added if required and can be well defined.
2023-10-21 15:45:30 +02:00
|
|
|
void visit(AstNode* nodep) override { countThenIterateChildren(nodep); }
|
|
|
|
|
|
2006-08-26 13:35:28 +02:00
|
|
|
public:
|
|
|
|
|
// CONSTRUCTORS
|
Simplify and fix code stats
V3Stats for "fast" code have bit-rotted a little and is causing some
problems with tests that rely on stats outputs. The problem is that not
all code is necessarily reachable from eval() any more (due to the
complexity of some the features added over the past few years), so it
might miss some things, as for measuring the "fast" code, it is trying
to trace the execution paths via calls, starting from eval(). It also
appears the fast code can also contain calls to slow code in some
circumstances.
To avoid all that, removed trying to trace dynamic execution, and simply
report the static node counts, which is enough for testing.
Similarly, the variable counts are somewhat dubious, as they don't
include all data types, or all instances of a module in some stages.
Removing these as they are not widely used nor dependable. More specific
stats can be added if required and can be well defined.
2023-10-21 15:45:30 +02:00
|
|
|
StatsVisitor(AstNetlist* nodep, const std::string& stage, bool fastOnly)
|
|
|
|
|
: m_fastOnly{fastOnly}
|
|
|
|
|
, m_accump{fastOnly ? &m_dumpster : &m_counters} {
|
|
|
|
|
UINFO(9, "Starting stats, fastOnly=" << fastOnly << endl);
|
|
|
|
|
memset(&m_counters, 0, sizeof(m_counters));
|
|
|
|
|
memset(&m_dumpster, 0, sizeof(m_dumpster));
|
|
|
|
|
|
2023-03-18 00:58:53 +01:00
|
|
|
iterateConst(nodep);
|
Simplify and fix code stats
V3Stats for "fast" code have bit-rotted a little and is causing some
problems with tests that rely on stats outputs. The problem is that not
all code is necessarily reachable from eval() any more (due to the
complexity of some the features added over the past few years), so it
might miss some things, as for measuring the "fast" code, it is trying
to trace the execution paths via calls, starting from eval(). It also
appears the fast code can also contain calls to slow code in some
circumstances.
To avoid all that, removed trying to trace dynamic execution, and simply
report the static node counts, which is enough for testing.
Similarly, the variable counts are somewhat dubious, as they don't
include all data types, or all instances of a module in some stages.
Removing these as they are not widely used nor dependable. More specific
stats can be added if required and can be well defined.
2023-10-21 15:45:30 +02:00
|
|
|
|
|
|
|
|
// Shorthand
|
|
|
|
|
const auto addStat = [&](const std::string& name, double count) { //
|
|
|
|
|
V3Stats::addStat(stage, name, count);
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
// Variable widths
|
2020-04-14 04:51:35 +02:00
|
|
|
for (unsigned i = 0; i < m_statVarWidths.size(); i++) {
|
Simplify and fix code stats
V3Stats for "fast" code have bit-rotted a little and is causing some
problems with tests that rely on stats outputs. The problem is that not
all code is necessarily reachable from eval() any more (due to the
complexity of some the features added over the past few years), so it
might miss some things, as for measuring the "fast" code, it is trying
to trace the execution paths via calls, starting from eval(). It also
appears the fast code can also contain calls to slow code in some
circumstances.
To avoid all that, removed trying to trace dynamic execution, and simply
report the static node counts, which is enough for testing.
Similarly, the variable counts are somewhat dubious, as they don't
include all data types, or all instances of a module in some stages.
Removing these as they are not widely used nor dependable. More specific
stats can be added if required and can be well defined.
2023-10-21 15:45:30 +02:00
|
|
|
if (const uint64_t count = m_statVarWidths.at(i)) {
|
|
|
|
|
std::stringstream ss;
|
|
|
|
|
ss << "Vars, width " << std::setw(5) << std::dec << i;
|
|
|
|
|
const std::string prefix = ss.str();
|
2019-05-19 22:13:13 +02:00
|
|
|
if (v3Global.opt.statsVars()) {
|
Simplify and fix code stats
V3Stats for "fast" code have bit-rotted a little and is causing some
problems with tests that rely on stats outputs. The problem is that not
all code is necessarily reachable from eval() any more (due to the
complexity of some the features added over the past few years), so it
might miss some things, as for measuring the "fast" code, it is trying
to trace the execution paths via calls, starting from eval(). It also
appears the fast code can also contain calls to slow code in some
circumstances.
To avoid all that, removed trying to trace dynamic execution, and simply
report the static node counts, which is enough for testing.
Similarly, the variable counts are somewhat dubious, as they don't
include all data types, or all instances of a module in some stages.
Removing these as they are not widely used nor dependable. More specific
stats can be added if required and can be well defined.
2023-10-21 15:45:30 +02:00
|
|
|
for (const auto& it : m_statVarWidthNames.at(i)) {
|
|
|
|
|
addStat(prefix + " " + it.first, it.second);
|
2019-05-19 22:13:13 +02:00
|
|
|
}
|
|
|
|
|
} else {
|
Simplify and fix code stats
V3Stats for "fast" code have bit-rotted a little and is causing some
problems with tests that rely on stats outputs. The problem is that not
all code is necessarily reachable from eval() any more (due to the
complexity of some the features added over the past few years), so it
might miss some things, as for measuring the "fast" code, it is trying
to trace the execution paths via calls, starting from eval(). It also
appears the fast code can also contain calls to slow code in some
circumstances.
To avoid all that, removed trying to trace dynamic execution, and simply
report the static node counts, which is enough for testing.
Similarly, the variable counts are somewhat dubious, as they don't
include all data types, or all instances of a module in some stages.
Removing these as they are not widely used nor dependable. More specific
stats can be added if required and can be well defined.
2023-10-21 15:45:30 +02:00
|
|
|
addStat(prefix, count);
|
2019-05-19 22:13:13 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
Simplify and fix code stats
V3Stats for "fast" code have bit-rotted a little and is causing some
problems with tests that rely on stats outputs. The problem is that not
all code is necessarily reachable from eval() any more (due to the
complexity of some the features added over the past few years), so it
might miss some things, as for measuring the "fast" code, it is trying
to trace the execution paths via calls, starting from eval(). It also
appears the fast code can also contain calls to slow code in some
circumstances.
To avoid all that, removed trying to trace dynamic execution, and simply
report the static node counts, which is enough for testing.
Similarly, the variable counts are somewhat dubious, as they don't
include all data types, or all instances of a module in some stages.
Removing these as they are not widely used nor dependable. More specific
stats can be added if required and can be well defined.
2023-10-21 15:45:30 +02:00
|
|
|
|
2019-05-19 22:13:13 +02:00
|
|
|
// Node types
|
Simplify and fix code stats
V3Stats for "fast" code have bit-rotted a little and is causing some
problems with tests that rely on stats outputs. The problem is that not
all code is necessarily reachable from eval() any more (due to the
complexity of some the features added over the past few years), so it
might miss some things, as for measuring the "fast" code, it is trying
to trace the execution paths via calls, starting from eval(). It also
appears the fast code can also contain calls to slow code in some
circumstances.
To avoid all that, removed trying to trace dynamic execution, and simply
report the static node counts, which is enough for testing.
Similarly, the variable counts are somewhat dubious, as they don't
include all data types, or all instances of a module in some stages.
Removing these as they are not widely used nor dependable. More specific
stats can be added if required and can be well defined.
2023-10-21 15:45:30 +02:00
|
|
|
const auto typeName = [](int type) { return std::string{VNType{type}.ascii()}; };
|
|
|
|
|
for (int t = 0; t < VNType::_ENUM_END; ++t) {
|
|
|
|
|
if (const uint64_t count = m_counters.m_statTypeCount[t]) {
|
|
|
|
|
addStat("Node count, " + typeName(t), count);
|
2019-05-19 22:13:13 +02:00
|
|
|
}
|
|
|
|
|
}
|
Simplify and fix code stats
V3Stats for "fast" code have bit-rotted a little and is causing some
problems with tests that rely on stats outputs. The problem is that not
all code is necessarily reachable from eval() any more (due to the
complexity of some the features added over the past few years), so it
might miss some things, as for measuring the "fast" code, it is trying
to trace the execution paths via calls, starting from eval(). It also
appears the fast code can also contain calls to slow code in some
circumstances.
To avoid all that, removed trying to trace dynamic execution, and simply
report the static node counts, which is enough for testing.
Similarly, the variable counts are somewhat dubious, as they don't
include all data types, or all instances of a module in some stages.
Removing these as they are not widely used nor dependable. More specific
stats can be added if required and can be well defined.
2023-10-21 15:45:30 +02:00
|
|
|
|
|
|
|
|
// Expression combinations
|
|
|
|
|
for (int t1 = 0; t1 < VNType::_ENUM_END; ++t1) {
|
|
|
|
|
for (int t2 = 0; t2 < VNType::_ENUM_END; ++t2) {
|
|
|
|
|
if (const uint64_t c = m_counters.m_statAbove[t1][t2]) {
|
|
|
|
|
addStat("Expr combination, " + typeName(t1) + " over " + typeName(t2), c);
|
2019-05-19 22:13:13 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
Simplify and fix code stats
V3Stats for "fast" code have bit-rotted a little and is causing some
problems with tests that rely on stats outputs. The problem is that not
all code is necessarily reachable from eval() any more (due to the
complexity of some the features added over the past few years), so it
might miss some things, as for measuring the "fast" code, it is trying
to trace the execution paths via calls, starting from eval(). It also
appears the fast code can also contain calls to slow code in some
circumstances.
To avoid all that, removed trying to trace dynamic execution, and simply
report the static node counts, which is enough for testing.
Similarly, the variable counts are somewhat dubious, as they don't
include all data types, or all instances of a module in some stages.
Removing these as they are not widely used nor dependable. More specific
stats can be added if required and can be well defined.
2023-10-21 15:45:30 +02:00
|
|
|
|
|
|
|
|
// Branch predictions
|
|
|
|
|
for (int t = 0; t < VBranchPred::_ENUM_END; ++t) {
|
|
|
|
|
if (const uint64_t c = m_counters.m_statPred[t]) {
|
|
|
|
|
addStat(std::string{"Branch prediction, "} + VBranchPred{t}.ascii(), c);
|
2019-05-19 22:13:13 +02:00
|
|
|
}
|
|
|
|
|
}
|
2006-08-26 13:35:28 +02:00
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
//######################################################################
|
|
|
|
|
// Top Stats class
|
|
|
|
|
|
Simplify and fix code stats
V3Stats for "fast" code have bit-rotted a little and is causing some
problems with tests that rely on stats outputs. The problem is that not
all code is necessarily reachable from eval() any more (due to the
complexity of some the features added over the past few years), so it
might miss some things, as for measuring the "fast" code, it is trying
to trace the execution paths via calls, starting from eval(). It also
appears the fast code can also contain calls to slow code in some
circumstances.
To avoid all that, removed trying to trace dynamic execution, and simply
report the static node counts, which is enough for testing.
Similarly, the variable counts are somewhat dubious, as they don't
include all data types, or all instances of a module in some stages.
Removing these as they are not widely used nor dependable. More specific
stats can be added if required and can be well defined.
2023-10-21 15:45:30 +02:00
|
|
|
void V3Stats::statsStageAll(AstNetlist* nodep, const std::string& stage, bool fastOnly) {
|
|
|
|
|
StatsVisitor{nodep, stage, fastOnly};
|
2006-08-26 13:35:28 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void V3Stats::statsFinalAll(AstNetlist* nodep) {
|
Simplify and fix code stats
V3Stats for "fast" code have bit-rotted a little and is causing some
problems with tests that rely on stats outputs. The problem is that not
all code is necessarily reachable from eval() any more (due to the
complexity of some the features added over the past few years), so it
might miss some things, as for measuring the "fast" code, it is trying
to trace the execution paths via calls, starting from eval(). It also
appears the fast code can also contain calls to slow code in some
circumstances.
To avoid all that, removed trying to trace dynamic execution, and simply
report the static node counts, which is enough for testing.
Similarly, the variable counts are somewhat dubious, as they don't
include all data types, or all instances of a module in some stages.
Removing these as they are not widely used nor dependable. More specific
stats can be added if required and can be well defined.
2023-10-21 15:45:30 +02:00
|
|
|
statsStageAll(nodep, "Final all");
|
|
|
|
|
statsStageAll(nodep, "Final fast", true);
|
2006-08-26 13:35:28 +02:00
|
|
|
}
|