On Thu, Sep 18, 2014 at 1:54 PM, Alan Lawrence <alan.lawre...@arm.com> wrote: > These match their corresponding tree codes, by taking a vector and returning > a scalar; this is more architecturally neutral than the (somewhat loosely > defined) previous optab that took a vector and returned a vector with the > result in the least significant bits (i.e. element 0 for little-endian or > N-1 for bigendian). However, the old optabs are preserved so as not to break > existing backends, so clients check for both old + new optabs. > > Bootstrap, check-gcc and check-g++ on x86_64-none-linux-gnu. > aarch64.exp + vect.exp on aarch64{,_be}-none-elf. > (of course at this point in the series all these are using the old optab + > migration path.)
scalar_reduc_to_vector misses a comment. I wonder if at the end we wouldn't transition all backends and then renaming reduc_*_scal_optab back to reduc_*_optab makes sense. The optabs have only one mode - I wouldn't be surprised if an ISA invents for example v4si -> di reduction? So do we want to make reduc_plus_scal_optab a little bit more future proof (maybe there is already an ISA that supports this kind of reduction?). Otherwise the patch looks good to me. Thanks, Richard. > gcc/ChangeLog: > > * doc/md.texi (Standard Names): Add reduc_(plus,[us](min|max))|scal > optabs, and note in reduc_[us](plus|min|max) to prefer the former. > > * expr.c (expand_expr_real_2): Use reduc_..._scal if available, fall > back to old reduc_... + BIT_FIELD_REF only if not. > > * optabs.c (optab_for_tree_code): for REDUC_(MAX,MIN,PLUS)_EXPR, > return the reduce-to-scalar (reduc_..._scal) optab. > (scalar_reduc_to_vector): New. > > * optabs.def (reduc_smax_scal_optab, reduc_smin_scal_optab, > reduc_plus_scal_optab, reduc_umax_scal_optab, > reduc_umin_scal_optab): > New. > > * optabs.h (scalar_reduc_to_vector): Declare. > > * tree-vect-loop.c (vectorizable_reduction): Look for optabs > reducing > to either scalar or vector.