On Fri, 24 Oct 2014, Alan Lawrence wrote: > This is the first half of my previous patch series > (https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01456.html), that is the part > making the REDUC_..._EXPR tree codes endian-neutral, and adding a new > reduce-to-scalar optab in place of the endianness-dependent > reduc_[us](plus|min|max)_optab. > > I'm leaving the vec_shr portion out of this patch series, as the link between > the two halves is only the end goal of removing an "if (BYTES_BIG_ENDIAN)" > from tree-vect-loop.c; this series removes that from one code path so can > stand alone. > > Patches 1-6 are as previously posted apart from rebasing and removing the > old/poisoned AArch64 patterns as per maintainer's request. Patches 1, 2, 4, 5 > and 6 have already been approved; patch 3 was discussed somewhat but I think > we decided against most of the ideas raised, I have added comment to > scalar_reduc_to_vector. I now reread Richie's "Otherwise the patch looks good > to me" and wonder if I should have taken that as an approval but I didn't read > it that way at the time...???
Yes, it was an approval ;) > 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 > leaving that for now. Also I haven't migrated (or worked out how to target) > rs6000/paired.md, help would be most welcome. > > > The suggestion was then to "complete" the migration, by removing the old > optabs. There are a few options here and I'll follow up with appropriate > patches according to feedback received. I see options: > > (1) just delete the old optabs (and the migration code). This would > performance-regress the MIPS backend, but should not break it, although one > should really do *something* with the then-unused > reduc_[us](plus|min|max)_optab in config/mips/loongson.md. > > (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. > > (2a) Alternatively I could just use a different new name, e.g. reduce_...., > reduct_...., vec_reduc_..., anything that's less of a mouthful than > reduc_..._scal. Whilst being only-very-slightly-different from the current > reduc_... might be confusing, so might changing the meaning of the optab, and > its signature, with the existing name, so am open to suggestions? I definitely prefer (2). Thanks, Richard.
