On Mon, May 11, 2020 at 10:56 PM Bill Schmidt <wschm...@linux.ibm.com> wrote:
>
> On 5/11/20 9:48 AM, David Edelsohn wrote:
> > On Sun, May 10, 2020 at 9:14 AM Bill Schmidt <wschm...@linux.ibm.com> wrote:
> >> From: Kelvin Nilsen <kel...@gcc.gnu.org>
> >>
> >> Add new insns vextdu[bhw]vlx, vextddvlx, vextdu[bhw]vhx, and
> >> vextddvhx, along with built-in access and overloaded built-in
> >> access to these insns.
> >>
> >> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
> >> regressions, using a Power9 configuration. Is this okay for
> >> master?
> >>
> >> Thanks,
> >> Bill
> >>
> >> [gcc]
> >>
> >> 2020-05-10 Kelvin Nilsen <kel...@gcc.gnu.org>
> >>
> >> * config/rs6000/altivec.h (vec_extractl): New #define.
> >> (vec_extracth): Likewise.
> >> * config/rs6000/altivec.md (UNSPEC_EXTRACTL): New constant.
> >> (UNSPEC_EXTRACTR): Likewise.
> >> (VEXTRACT_LR): New int iterator.
> > Well now the previous VSTRIR/VSTRIL patch is inconsistent. If we're
> > going to use an iterator for "LR", that's fine, but it needs to be
> > used consistently for similar situations. The approach for the two,
> > similar instructions and issues need to match.
>
>
> I see your point. I don't really like the way this was done very much,
> since the attributes are tied to the unspecs for extract-{low,high}.
> Simple attribute names like LR, lr, rl shouldn't be scoped so narrowly.
>
> I don't like any of the alternatives very well, either. I could either
> (1) change the names of the int iterators in this patch to incorporate
> part of the word "extract", and create similar iterators for the
> vstril/vstrir patterns; or (2) remove the iterators from this patch and
> just create two expansions and two insns instead of one of each. I have
> a slight preference for (2) since the longer iterator names will make
> things ugly.
>
> Do you or Segher have a preference?
Hi, Bill
I don't have a particular preference. Maybe Segher sees more future
implications from one choice or the other.
It's easy enough to create a more generic iterator name (LEFTRIGHT_ITERATOR).
Some of the earlier even/odd patterns with endian fixes required more
adjustment to one or the other, so it couldn't use a simple iterator,
which means we can't be completely consistent. I would prefer that if
an endian fixup pattern can use an iterator, we either always use one
or never use one, not this mix and match. It should be a consistent
style and implementation in the rs6000 port.
Thanks, David
