On Fri, Oct 24, 2014 at 5:17 PM, Matthew Fortune <matthew.fort...@imgtec.com> wrote: > Alan Lawrence <alan.lawre...@arm.com> writes: >> Patches 7-11 migrate migrate ARM, x86, IA64 (I think), and mostly PowerPC, >> to >> the new reduc_(plus|[us](min|max))_scal_optab. I have not managed to work >> out >> how to do the same for MIPS (specifically what I need to add to >> mips_expand_vec_reduc), and have had no response from the maintainers, so >> am > > Sorry, I was looking at this but failed to send an email saying so. The lack > of vec_extract appears to be the stumbling point here so at the very least > we need to add a naïve version of that I believe. > >> (2) also renaming reduc_..._scal_optab back to reduc_..._optab; would >> break the >> MIPS backend if something were not done with it's existing patterns. > > I suspect we can deal with this in time to make a rename OK. > > One thing occurred to me about this change in general which is that on the > whole the reduction to a scalar seems good for an epilogue but is there > a problem if the result is then replicated across a vector for further > processing. I.e. a vector is reduced to a scalar, which moves the value > from a SIMD register to a GP register (because scalar modes are not > supported in SIMD registers generally) and then gets moved back to a > SIMD register to form part of a new vector? Would you expect the > redundant moves to get eliminated?
Combine should be able to do this if you help it (it of course depends on what your actual processor instruction doing the reduction does). Richard. > Thanks, > Matthew
