Fix for matvec-prod - Re: [patch] Dispatch fixes

[Jules Bergmann]

Jules Bergmann wrote:
> This patch fixes a couple of dispatch issues:
> 
>  - First, it updates the SAL and IPP dispatch to explicitly request
>    1-dimensional Ext_data access.  This is necessary when dealing with
>    multi-dimensional data that has been forwarded by the
>    eval_dense_expr.
>  - Second, it updates the SAL dispatch evaluators to use SFINAE to only
>    enable themselves if their expected leaf blocks match those of the
>    expression.  This prevents the (VV)V and V(VV) evaluators from being
>    ambiguous for expressions like (VV)(VV) (Neither one is enabled.)
>  - Finally fixes a bug when a Redim_block is applied to a 3-dimensional
>    block that resulted in the wrong stride being reported.
> 
> With this patch in place, all tests pass (with the exception of 
> ref-impl/solver-qr which requires a full QR) for the configuration 
> Stefan posted Wednesday, including matvec.cpp.

Stefan,

With this patch, the matvec.cpp and/or matvec-prod.cpp failures should 
have been fixed.  IIRC believe the problem was with gems (generlized 
matrix sum), which does:

	C = alpha * A + beta * C;

This was getting redispatched from a matrix expression to a vector 
expression.  However, SAL dispatch hadn't been updated to handle this 
properly (Ext_data by default uses Block::dim to determine 
dimensionality, which breaks when a 2-D dense block is used in a 1-D 
context.  The fix is to tell Ext_data which dimensionality to use).

Let me know if IPP is still broken with this patch.

				-- Jules


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