[patch] Profiling policies for the serial expression evaluator.
Jules Bergmann
jules at codesourcery.com
Mon Aug 14 21:13:17 UTC 2006
This patch adds the ability to plug "profiling policies" into the
expression dispatch. The idea is that this will let us insert profiling
(or coverage) code in one place that gets used for all the different
expression evaluators out there.
A profiling policy is a class template that:
1) has on template parameter 'EvalExpr', which is used by the dispatch
to tell the policy which expression evaluator will be used for the
expression.
2) has a templated constructor that takes the 'SrcBlock' and 'DstBlock'
parameters.
For example, the profiling policy for inserting coverage looks like:
template <typename EvalExpr>
struct Eval_coverage_policy
{
template <typename DstBlock,
typename SrcBlock>
Eval_coverage_policy(DstBlock const&, SrcBlock const&)
{
char const* evaluator_name = EvalExpr::name();
VSIPL_IMPL_COVER_BLK(evaluator_name, SrcBlock);
}
};
This policy class gets instantiated by the Serial_dispatch_helper class
in its exec body (ProfileP is a new template parameter for
Serial_dispatch_helper that is used to indicate the policy):
struct Serial_dispatch_helper<...>
{
static void exec(DstBlock& dst, SrcBlock const& src)
VSIP_NOTHROW
{
if (EvalExpr::rt_valid(dst, src))
{
ProfileP<EvalExpr> profile(dst, src);
EvalExpr::exec(dst, src);
}
else ...
}
};
When the policy gets instantiated, it knows which evaluator has been
selected, along with the expression being evaluated. Because it is
instantiated before the expression is evaluated and has scope that ends
once the expression has been evaluated, it should be easy to insert a
Scope_event member to profile expressions.
This patch adds a 'name()' member function to all the
Serial_expr_evaluator specializations that returns the name of the
evaluator. For example, the 1-dimensional Loop_fusion_tag evaluator
returns the string "SEE_1". The profiling policy can use this to get
the name of the evaluator.
Right now, this patch looses some of the detail that Don's profiling
patch is able to see (for example, it currently does not distinguish
whether a 2-dim loop fusion is done with row-major or column-major
traversal). However, it should be easy to get that back by extending
the 2-dim loop fusion name function to determine whether row-major or
col-major traversal will be done (it has enough info to do that). I.e.
static char const* name()
{
typedef typename Block_layout<DstBlock>::order_type
dst_order_type;
if (Type_equal<dst_order_type, row2_type>::value)
return "SEE_2_row";
else
return "SEE_2_col";
}
The patch also works for coverage, allowing us to replace the COVERAGE_
statements sprinkled throughout most (but not all) of the evaluators
with a single policy that does coverage for evaluators.
This also adds a new class 'Serial_dispatch' that is a front-end to
'Serial_dispatch_helper'. It is responsible for choosing the
appropriate policy, based on whether profiling and coverage are enabled.
Don, do you think that you can work the expression profiling into this
framework?
-- Jules
--
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: eval-policy.diff
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060814/76936c30/attachment.ksh>
More information about the vsipl++
mailing list