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?
Thanks!
Bill
Thanks, David
