[vsipl++] [patch] Use new dispatch for matvec functions

[Jules Bergmann]

Don McCoy wrote:
> This patch has been expanded to include SAL and CML matvec functions and 
> it completely replaces previous versions.  It also incorporates the 
> feedback received from Stefan.  BLAS modifications will be posted in a 
> later patch.
> 
> Ok to commit?

Don,

I have several comments below.  Otherwise it looks good.

			thanks,
			-- Jules



> Index: src/vsip/core/cvsip/matvec.hpp
> ===================================================================
> --- src/vsip/core/cvsip/matvec.hpp	(revision 225932)
> +++ src/vsip/core/cvsip/matvec.hpp	(working copy)
> @@ -158,82 +158,47 @@
>  
>  } // namespace vsip::impl::cvsip
>  
> +namespace dispatcher
> +{
> +
>  template <typename T,
> -          typename Block1,
> -          typename Block2>
> -struct Evaluator<Op_prod_vv_dot, Return_scalar<T>, Op_list_2<Block1, Block2>,
> -                 Cvsip_tag>
> +          typename Block0,
> +          typename Block1>
> +struct Evaluator<Op_prod_vv_dot, Cvsip_tag,
> +                 Return_scalar<T>(Block0 const&, Block1 const&)>

[1] I don't think the new dispatcher needs the Return_scalar<T>.  Just
T should be fine.

Return_scalar helped general dispatch determine wehther the exec
function gave its result as a return value (mostly scalars) or as a
by-reference variable (mostly blocks).  The new dispatcher uses
function type to indicate this without ambiguity.



>  
> -template <typename T,
> -          typename Block1,
> -          typename Block2>
> -struct Evaluator<Op_prod_vv_dot, Return_scalar<std::complex<T> >,
> -                 Op_list_2<Block1, 
> -                           Unary_expr_block<1, conj_functor,
> -                                            Block2, std::complex<T> > const>,
> -                 Cvsip_tag>

[2] Why is this evaluator being removed?

> -{
> -  typedef cvsip::Op_traits<std::complex<T> > traits;
> -  typedef Unary_expr_block<1, conj_functor, Block2, complex<T> > block2_type;
>  
> -  static bool const ct_valid = 
> -    traits::valid &&
> -    Type_equal<complex<T>, typename Block1::value_type>::value &&
> -    Type_equal<complex<T>, typename Block2::value_type>::value &&
> -    // check that direct access is supported
> -    Ext_data_cost<Block1>::value == 0 &&
> -    Ext_data_cost<Block2>::value == 0;
> -
> -  static bool rt_valid(Block1 const&, block2_type const&)
> -  { return true; }
> -
> -  static complex<T> exec(Block1 const& a, block2_type const& b)
> -  {
> -    VSIP_IMPL_COVER_FCN("Op_prod_vv_dot(conj)/cvsip", exec);
> -    assert(a.size(1, 0) == b.size(1, 0));
> -
> -    Ext_data<Block1> ext_a(const_cast<Block1&>(a));
> -    Ext_data<Block2> ext_b(const_cast<Block2&>(b.op()));
> -    cvsip::View<1, std::complex<T> >
> -      aview(ext_a.data(), 0, ext_a.stride(0), a.size(1, 0));
> -    cvsip::View<1, std::complex<T> >
> -      bview(ext_b.data(), 0, ext_b.stride(0), b.size(1, 0));
> -    return traits::cvjdot(aview.ptr(), bview.ptr());
> -  }
> -};
> -

> +/* Copyright (c) 2008 by CodeSourcery.  All rights reserved. */
> +
> +/** @file    vsip/core/dispatch.hpp
> +    @author  Stefan Seefeld
> +    @date    2006-11-03
> +    @brief   VSIPL++ Library: Dispatcher harness.

[3] Can you adjust the author/date and mention that this file contains
a simplified dispatch harness for the reference implementation and
that the real slim shady is in opt/dispatch.hpp.



> +/// Generic evaluator for vector-vector dot-product.
> +template <typename T,
> +	  typename Block0,
> +	  typename Block1>
> +struct Evaluator<Op_prod_vv_dot, Generic_tag,
> +                 T(Block0 const&, Block1 const&)>
> +{
> +  static bool const ct_valid = true;
> +  static bool rt_valid(Block0 const&, Block1 const&) { return true; }
> +
> +  static T exec(Block0 const& a, Block1 const& b)
> +  {
> +    assert(a.size(1, 0) == b.size(1, 0));
> +
> +    T r = T();
> +    for ( index_type i = 0; i < a.size(); ++i )
> +      r += a.get(i) * b.get(i);
> +    return r;
> +  }
> +};
> +
> +template <typename T,
> +	  typename Block0,
> +	  typename Block1>
> +struct Evaluator<Op_prod_vv_dot, Generic_tag,
> +                 std::complex<T>(Block0 const&, 
> +                   Unary_expr_block<1, conj_functor, Block1, std::complex<T> > const&)>

[4] Why is this evaluator necessary?  The Unar_expr_block specialization
isn't used at all: the exec() body is identical to the more generic
evaluator above.

> +{
> +  typedef Unary_expr_block<1, conj_functor, Block1, std::complex<T> > block1_type;
> +
> +  static bool const ct_valid = true;
> +  static bool rt_valid(Block0 const&, block1_type const&) { return true; }
> +
> +  static std::complex<T> exec(Block0 const& a, block1_type const& b)
> +  {
> +    assert(a.size(1, 0) == b.size(1, 0));
> +
> +    std::complex<T> r = std::complex<T>();
> +    for ( index_type i = 0; i < a.size(); ++i )
> +      r += a.get(i) * b.get(i);
> +    return r;
> +  }
> +};

-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705