[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