http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374
--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-09-22 15:52:11 UTC --- The reason why many of the loops in *-12.c aren't vectorized is that for idxtype other than unsigned int which is the type of i there is a cast from i to the type of pos. OT, one big disadvantage of the latest patch is that the code to compute the extreme is different between normal smin/smax/umin/umax reduction and between the first part of the min/max_loc reduction - the former is faster and only computes the extreme in the lowest element of the vector, while the latter computes it duplicated in all vector elements. Which means if a loop wants to compute both the extreme and position of the extreme, it now results in unnecessary extra instructions. We don't support currently two results operations in GIMPLE, so I wonder how to express that. Perhaps use different min/max reduction expression in that case? Say REDUC_MIN_LOC_VALUE_EXPR etc., which would use reduc_min_loc_* optab to expand as well? That optab would have two targets, and if we wanted to expand REDUC_MIN_LOC_EXPR, we'd use one of the targets and pass a gen_reg_rtx () to the other one, for REDUC_MIN_LOC_VALUE_EXPR the other way around. Thoughts?
