Add a Score gcc maintainer
Hello gcc maintainers: I'm Qinwei from Sunnorth. I volunteer to be a Score gcc maintainer and I'm eager to do more contributions to gcc. Previously i maintained Score gdb, binutils and glibc rtld for Sunnorth. Could i do that? If i could, what should i do? -- Best regards, Qinwei
Re: Add a Score gcc maintainer
On Wed, Mar 2, 2011 at 2:07 PM, Qin wei wrote: > Hello gcc maintainers: > > I'm Qinwei from Sunnorth. I volunteer to be a Score gcc maintainer and > I'm eager to do more contributions to gcc. Previously i maintained > Score gdb, binutils and glibc rtld for Sunnorth. Could i do that? If i > could, what should i do? SCORE lacks somebody monitoring the GCC development trunk making sure that 1) it builds, 2) it works (*) Richard. (*) perform testsuite runs, monitor and address regressions and regularly post testresults to gcc-testresults
Re: Add a Score gcc maintainer
> > SCORE lacks somebody monitoring the GCC development trunk making > sure that 1) it builds, 2) it works (*) > > Richard. > > (*) perform testsuite runs, monitor and address regressions and regularly > post testresults to gcc-testresults > Hi Richard, We are doing this thing now, you will see the result soon. Thanks, --liqin
Re: how can I write a right V32QI Unpack Low Data insn pattern?
On 02/03/2011 07:56, Liu wrote:
> The wrong code is :
> L9284: ATTRIBUTE_UNUSED_LABEL
> x3 = XEXP (x2, {);
> if (x3 == const_int_rtx[MAX_SAVED_CONST_INT + (13)])
> goto L9285;
> goto ret0;
>
> L9285: ATTRIBUTE_UNUSED_LABEL
> x3 = XEXP (x2, |);
> if (x3 == const_int_rtx[MAX_SAVED_CONST_INT + (45)])
> goto L9286;
> goto ret0;
>
> L9286: ATTRIBUTE_UNUSED_LABEL
> x3 = XEXP (x2, });
> if (x3 == const_int_rtx[MAX_SAVED_CONST_INT + (14)])
> goto L9287;
> goto ret0;
>
> L9287: ATTRIBUTE_UNUSED_LABEL
> x3 = XEXP (x2, ~);
> if (x3 == const_int_rtx[MAX_SAVED_CONST_INT + (46)])
> goto L9288;
> goto ret0;
Well, that's coming from here:
else
printf ("%sx%d = XEXP (x%d, %c);\n",
indent, depth + 1, depth, newpos[depth]);
++depth;
at the end of genrecog.c#change_state(). The problematic position string is
presumably being generated here:
if (was_code == MATCH_OPERATOR || was_code == MATCH_PARALLEL)
{
char base = (was_code == MATCH_OPERATOR ? '0' : 'a');
for (i = 0; i < (size_t) XVECLEN (pattern, 2); i++)
{
subpos[depth] = i + base;
sub = add_to_sequence (XVECEXP (pattern, 2, i),
&sub->success, subpos, insn_type, 0);
}
}
in the MATCH_OPERAND case of the big switch in add_to_sequence(). Possibly
change_state needs to do something like
printf ("%sx%d = XEXP (x%d, %d);\n",
indent, depth + 1, depth,
newpos[depth] > 'a'
? newpos[depth] - 'a'
: newpos[depth] - '0');
... but you need someone who understands genrecog and how the position string
representations are supposed to work to advise you here, and that's not me I'm
afraid.
cheers,
DaveK
Re: Add a Score gcc maintainer
On Wed, Mar 2, 2011 at 8:07 AM, Qin wei wrote: > Hello gcc maintainers: > > I'm Qinwei from Sunnorth. I volunteer to be a Score gcc maintainer and > I'm eager to do more contributions to gcc. Previously i maintained > Score gdb, binutils and glibc rtld for Sunnorth. Could i do that? If i > could, what should i do? Qinwei, There may be confusion over terminology. A GCC maintainer is someone who may approve patches to some area of the compiler; it does not restrict who may develop or contribute patches to an area of the compiler. To contribute patches, one needs an FSF assignment, but one does not need to be appointed as a maintainer. You and Liqin needs to decide who will be in charge of the SCORE target port. If both of you should be maintainers, that is okay and the GCC SC will consider it. The GCC SC wants to see some example of experience working on the port and the with the GCC community. The main thing we need to see now is active maintenance of the port. Thanks, David
Re: how can I write a right V32QI Unpack Low Data insn pattern?
Dave Korn writes:
> On 02/03/2011 07:56, Liu wrote:
>
>> The wrong code is :
>> L9284: ATTRIBUTE_UNUSED_LABEL
>> x3 = XEXP (x2, {);
>> if (x3 == const_int_rtx[MAX_SAVED_CONST_INT + (13)])
>> goto L9285;
>> goto ret0;
>
> Well, that's coming from here:
>
> else
> printf ("%sx%d = XEXP (x%d, %c);\n",
> indent, depth + 1, depth, newpos[depth]);
> ++depth;
Interesting. Looks you have a define_insn which has too many entries.
It can only have 26 elements, but, annoyingly, genrecog doesn't check
for that.
It's a bit odd to have more than 26 elements. Do you have any
incredibly large define_insn patterns?
> in the MATCH_OPERAND case of the big switch in add_to_sequence(). Possibly
> change_state needs to do something like
>
> printf ("%sx%d = XEXP (x%d, %d);\n",
> indent, depth + 1, depth,
> newpos[depth] > 'a'
> ? newpos[depth] - 'a'
> : newpos[depth] - '0');
No, change_state uses upper case and lower case letters to mean
different things. In this case it's meant to be a lower case letter but
it has overrun.
This patch should at least cause genrecog to crash for you rather than
generating bogus output. I've verified that this patch bootstraps on
x86_64 and makes no difference in the generated insn-recog.c. Can you
see whether this gives you a crash? Any opinion on whether I should
commit this to mainline?
Ian
Index: genrecog.c
===
--- genrecog.c (revision 169848)
+++ genrecog.c (working copy)
@@ -912,6 +912,7 @@ add_to_sequence (rtx pattern, struct dec
/* Which insn we're looking at is represented by A-Z. We don't
ever use 'A', however; it is always implied. */
+ gcc_assert (i < 26);
subpos[depth] = (i > 0 ? 'A' + i : 0);
sub = add_to_sequence (XVECEXP (pattern, 0, i),
last, subpos, insn_type, 0);
@@ -1002,6 +1003,9 @@ add_to_sequence (rtx pattern, struct dec
char base = (was_code == MATCH_OPERATOR ? '0' : 'a');
for (i = 0; i < (size_t) XVECLEN (pattern, 2); i++)
{
+ gcc_assert (was_code == MATCH_OPERATOR
+ ? ISDIGIT (i + base)
+ : ISLOWER (i + base));
subpos[depth] = i + base;
sub = add_to_sequence (XVECEXP (pattern, 2, i),
&sub->success, subpos, insn_type, 0);
@@ -1102,6 +1106,7 @@ add_to_sequence (rtx pattern, struct dec
int j;
for (j = 0; j < XVECLEN (pattern, i); j++)
{
+ gcc_assert (j < 26);
subpos[depth] = 'a' + j;
sub = add_to_sequence (XVECEXP (pattern, i, j),
&sub->success, subpos, insn_type, 0);
@@ -2528,6 +2533,7 @@ make_insn_sequence (rtx insn, enum routi
}
XVECLEN (x, 0) = j;
+ gcc_assert (j - 1 < 26);
c_test_pos[0] = 'A' + j - 1;
c_test_pos[1] = '\0';
}
Re: how can I write a right V32QI Unpack Low Data insn pattern?
On Wed, Mar 02, 2011 at 07:14:53AM -0800, Ian Lance Taylor wrote: > This patch should at least cause genrecog to crash for you rather than > generating bogus output. I've verified that this patch bootstraps on > x86_64 and makes no difference in the generated insn-recog.c. Can you > see whether this gives you a crash? Any opinion on whether I should > commit this to mainline? > > + gcc_assert (i < 26); > + gcc_assert (j < 26); > + gcc_assert (j - 1 < 26); Is it worthwhile pulling out the 26 into a #define somewhere? (Maybe not, as there are pre-existing 26-esque constants elsewhere?) -Nathan
TYPE_UID(node) macro value
Question, how is the uid for a type calculated? What are the contributing factors? Can I count on the uid for a type in a header to be the same across all compilation units that use that header? Cheers, Kyle
Re: new libjava bootstrap failure
On Wed, Mar 02, 2011 at 07:16:19AM +0100, Ralf Wildenhues wrote: > Hello Dave, > > * Dave Korn wrote on Wed, Mar 02, 2011 at 06:28:15AM CET: > > http://mad-scientist.net/make/autodep.html > > > > although note that where that recommends using "-include" (under > > "Avoiding ``No rule to make target ...'' Errors") to ignore would-be > > errors from trying to include non-existent files, we use an unprefixed > > include directive to read them in our Makefiles, and rely on > > config.status to generate empty ones first time round. I'm not sure > > why we do that differently. > > That's because non-GNU makes don't have facilities to include a file > only if it is present, and with the current machinery, a non-present > file always indicates a bug (or previous error) and having errors be > loud is a good thing for debugging. > > Jack, the actual issue you're seeing might well be the result of some > missing dependency. With parallel build failures, it is most important > to see output from make, back to at least the first error that happened. > That can be arbitrarily far back, and in GCC it is not uncommon to have > it happen a few thousand lines before the end of the log. Please save > such logs for future reports. > > Thanks, > Ralf Ralf, A second repetition of the original build with --enable-build-with-cxx completed without errors. FYI, I do all of my builds on darwin10 with lto-bootstrap and 'make -j 8'. This is the first time that I have seen this particular failure crop up. Jack
Re: TYPE_UID(node) macro value
Hi, On Wed, 2 Mar 2011, Kyle Girard wrote: > Question, how is the uid for a type calculated? What are the > contributing factors? It's simply a counter incremented each time a type node is created (see next_type_uid), hence ... > Can I count on the uid for a type in a header to be the same across all > compilation units that use that header? ... no. Ciao, Michael.
Re: how can I write a right V32QI Unpack Low Data insn pattern?
Nathan Froyd writes: > On Wed, Mar 02, 2011 at 07:14:53AM -0800, Ian Lance Taylor wrote: >> This patch should at least cause genrecog to crash for you rather than >> generating bogus output. I've verified that this patch bootstraps on >> x86_64 and makes no difference in the generated insn-recog.c. Can you >> see whether this gives you a crash? Any opinion on whether I should >> commit this to mainline? >> >> + gcc_assert (i < 26); >> +gcc_assert (j < 26); >> + gcc_assert (j - 1 < 26); > > Is it worthwhile pulling out the 26 into a #define somewhere? (Maybe > not, as there are pre-existing 26-esque constants elsewhere?) Sure, I can do that if other maintainers think the patch in general is a good idea. I think the number 26 is pretty obvious, though, in context. I don't think giving it a name will actually make it clearer. Ian
Re: TYPE_UID(node) macro value
> It's simply a counter incremented each time a type node is created (see > next_type_uid), hence ... > Thanks the info. > > Can I count on the uid for a type in a header to be the same across all > > compilation units that use that header? > > ... no. > Is there anyway in gcc to get a unique id for a type that would be the same across compilation units? Or would I have to come up with my own encoding somehow? Cheers, Kyle
GCC_FOR_TARGET settings being overridden by toplevel Makefile
We are trying to add some flags to GCC_FOR_TARGET so that when check-gcc runs, it includes a few extra sysroot and -isystem options. To do this, we've modified the definition in gcc/Makefile.in to add these extra options: -GCC_FOR_TARGET = $(STAGE_CC_WRAPPER) ./xgcc -B./ -B$(build_tooldir)/bin/ -isystem $(build_tooldir)/include -isystem $(build_tooldir)/sys-include -L$(objdir)/../ld +SYSROOT_CFLAGS_FOR_TARGET = @SYSROOT_CFLAGS_FOR_TARGET@ +GCC_FOR_TARGET = $(STAGE_CC_WRAPPER) $(shell $(PWD_COMMAND))/xgcc $(SYSROOT_CFLAGS_FOR_TARGET) -B$(shell ($PWD_COMMAND))/ -B$(build_tooldir)/bin/ -isystem $(build_tooldir)/include -isystem $(build_tooldir)/sys-include -L$(objdir)/../ld Additionally, we redefine GCC_UNDER_TEST to use GCC_FOR_TARGET in site.exp: @@ -4843,6 +4844,7 @@ site.exp: ./config.status Makefile @echo "set CXXFLAGS \"\"" >> ./tmp0 @echo "set HOSTCC \"$(CC)\"" >> ./tmp0 @echo "set HOSTCFLAGS \"$(CFLAGS)\"" >> ./tmp0 + @echo "set GCC_UNDER_TEST \"$(GCC_FOR_TARGET)\"" >> ./tmp0 When 'make check' runs from within the gcc/ directory, everything is fine, but when we run 'make check-gcc' from the toplevel build directory, the value for GCC_FOR_TARGET is explicitly passed to gcc/Makefile, which makes it ignore the new flags. This causes massive failures because of the missing arguments. I think that the simplest solution will be to define GCC_FOR_TARGET with 'override GCC_FOR_TARGET = ...' in gcc/Makefile.in and in any other Makefiles that need to use the additional flags. Does this sound like the right approach or should we be passing these flags some other way? We need something that passes our sysroot settings to all the testsuites. Thanks. Diego.
Re: TYPE_UID(node) macro value
Kyle Girard writes: > Is there anyway in gcc to get a unique id for a type that would be the > same across compilation units? Or would I have to come up with my own > encoding somehow? I don't know of anything like that in gcc today. The first thing you need to do is define when two types are the "same," a concept which some languages do not define clearly across compilation units. The middle-end more or less has such a meaning today, based on useless_type_conversion_p. Is that the meaning you want? Ian
Re: GCC_FOR_TARGET settings being overridden by toplevel Makefile
Diego Novillo writes: > We are trying to add some flags to GCC_FOR_TARGET so that when > check-gcc runs, it includes a few extra sysroot and -isystem options. > To do this, we've modified the definition in gcc/Makefile.in to add > these extra options: > > -GCC_FOR_TARGET = $(STAGE_CC_WRAPPER) ./xgcc -B./ > -B$(build_tooldir)/bin/ -isystem $(build_tooldir)/include -isystem > $(build_tooldir)/sys-include -L$(objdir)/../ld > +SYSROOT_CFLAGS_FOR_TARGET = @SYSROOT_CFLAGS_FOR_TARGET@ > +GCC_FOR_TARGET = $(STAGE_CC_WRAPPER) $(shell $(PWD_COMMAND))/xgcc > $(SYSROOT_CFLAGS_FOR_TARGET) -B$(shell ($PWD_COMMAND))/ > -B$(build_tooldir)/bin/ -isystem $(build_tooldir)/include -isystem > $(build_tooldir)/sys-include -L$(objdir)/../ld > > Additionally, we redefine GCC_UNDER_TEST to use GCC_FOR_TARGET in site.exp: > > @@ -4843,6 +4844,7 @@ site.exp: ./config.status Makefile > @echo "set CXXFLAGS \"\"" >> ./tmp0 > @echo "set HOSTCC \"$(CC)\"" >> ./tmp0 > @echo "set HOSTCFLAGS \"$(CFLAGS)\"" >> ./tmp0 > + @echo "set GCC_UNDER_TEST \"$(GCC_FOR_TARGET)\"" >> ./tmp0 > > When 'make check' runs from within the gcc/ directory, everything is > fine, but when we run 'make check-gcc' from the toplevel build > directory, the value for GCC_FOR_TARGET is explicitly passed to > gcc/Makefile, which makes it ignore the new flags. This causes > massive failures because of the missing arguments. > > I think that the simplest solution will be to define GCC_FOR_TARGET > with 'override GCC_FOR_TARGET = ...' in gcc/Makefile.in and in any > other Makefiles that need to use the additional flags. > > Does this sound like the right approach or should we be passing these > flags some other way? We need something that passes our sysroot > settings to all the testsuites. That does not sound like the right approach to me. Why not add the new flags to GCC_FOR_TARGET at top-level? It seems to me that GCC_FOR_TARGET should mean the same thing at all levels. If the flags are specific to testing, then put them in a new variable. You can still add them to GCC_UNDER_TEST in site.exp. Ian
Re: new libjava bootstrap failure
* Jack Howarth wrote on Wed, Mar 02, 2011 at 06:08:22PM CET: > On Wed, Mar 02, 2011 at 07:16:19AM +0100, Ralf Wildenhues wrote: > > Jack, the actual issue you're seeing might well be the result of some > > missing dependency. With parallel build failures, it is most important > > to see output from make, back to at least the first error that happened. > > That can be arbitrarily far back, and in GCC it is not uncommon to have > > it happen a few thousand lines before the end of the log. Please save > > such logs for future reports. > A second repetition of the original build with --enable-build-with-cxx > completed without errors. Race conditions can be very tricky to win; successful builds are never a proof of their absence. It might only happen again in a few months, or only under a certain system load. > FYI, I do all of my builds on darwin10 with > lto-bootstrap and 'make -j 8'. This is the first time that I have seen this > particular failure crop up. Well, please keep logs for the case when it might happen again. Thanks, Ralf
Re: gcc restores wrong stack pointer value?
On 02/26/2011 08:20 AM, DJ Delorie wrote: > Is this expected behavior? Do I need to do some magic in my epilogue > to further "fix" the stack pointer? Well, you can begin by honoring frame_pointer_needed properly. I can't see how m32c works with any function that uses alloca. You seem to be relying on the EXITD instruction to restore the stack pointer from the frame pointer, but doing so after actually using the invalid stack pointer to pop registers. r~
Re: how can I write a right V32QI Unpack Low Data insn pattern?
On 03/03/2011 01:14 AM, Ian Lance Taylor wrote: > This patch should at least cause genrecog to crash for you rather than > generating bogus output. I've verified that this patch bootstraps on > x86_64 and makes no difference in the generated insn-recog.c. Can you > see whether this gives you a crash? Any opinion on whether I should > commit this to mainline? Looks good to me. r~
Re: gcc restores wrong stack pointer value?
So... gcc assumes the register push/pops happen before the frame pointer is initialized? So the epilog always restores $sp from $fp before restoring registers? That would make the m32c port much less efficient, since it has the exitd opcode which restores $sp, releases the frame, and returns, all in one. But, why is it that gcc is *almost* doing what I expect? It *does* save the $sp value, and restores it before the epilogue, but it doesn't restore the value it has at the end of the prologue. I mean, if only it copied $sp to $a1 *before* mucking with $sp, it would have worked perfectly...
Re: gcc restores wrong stack pointer value?
On 03/03/2011 09:55 AM, DJ Delorie wrote: > So... gcc assumes the register push/pops happen before the frame > pointer is initialized? So the epilog always restores $sp from $fp > before restoring registers? Ah, I see you're one of the rare ! EXIT_IGNORE_STACK targets. There does seem to be an off-by-one problem in the insertion of the emit_stack_save code. I'll work on it. All that said, I can't imagine that !EXIT_IGNORE_STACK is actually more efficient than doing the right thing in the epilogue for any target. In the case of m32c, sure for very small functions you'll get enter pushm mov sp,a0 ... mov a0,sp popm exitd However, there are very very few registers on this target, and it seems exceedingly likely that any address register used here will get spilled. At which point you have a pair of load/store insns added to spill that value. Compare that to enter pushm ... movaofs[fb],a0 mov a0,sp popm exitd which never needs the pair of spill insns. Something to consider... r~
Re: gcc restores wrong stack pointer value?
> which never needs the pair of spill insns. Something to consider... Does gcc provide a flag that says "your $sp will be unspecified at the end of this function" that's valid during reload and for prologue and epilogue generation? I could push $pc onto the stack just after setting $fp, so it's always where I can get to it in the epilogue. Most of the time, $sp happems to have the original value anyway, so no registers are used and it just works.
Re: gcc restores wrong stack pointer value?
On 03/03/2011 11:49 AM, DJ Delorie wrote: >> which never needs the pair of spill insns. Something to consider... > > Does gcc provide a flag that says "your $sp will be unspecified at the > end of this function" that's valid during reload and for prologue and > epilogue generation? I could push $pc onto the stack just after > setting $fp, so it's always where I can get to it in the epilogue. > > Most of the time, $sp happems to have the original value anyway, so no > registers are used and it just works. See current_function_sp_is_unchanging. Also have a look at how that value is used in i386 epilogue expansion. Why would you push $pc? Or push anything for that matter... r~
Re: gcc restores wrong stack pointer value?
Doh, I suppose what I want is $sp, no, $fp, but that's where I'm storing it, so I suppose I could just set $sp from $fp+const, yes? It's an extra "restore sp from fp" but only when the frame size is variable.
Re: gcc restores wrong stack pointer value?
On 03/03/2011 12:04 PM, DJ Delorie wrote: > Doh, I suppose what I want is $sp, no, $fp, but that's where I'm > storing it, so I suppose I could just set $sp from $fp+const, yes? Yes. That's what I was trying to describe with that mova sequence. > It's an extra "restore sp from fp" but only when the frame size is > variable. Exactly. r~
Re: how can I write a right V32QI Unpack Low Data insn pattern?
On Wed, Mar 2, 2011 at 11:14 PM, Ian Lance Taylor wrote:
> Dave Korn writes:
>
>> On 02/03/2011 07:56, Liu wrote:
>>
>>> The wrong code is :
>>> L9284: ATTRIBUTE_UNUSED_LABEL
>>> x3 = XEXP (x2, {);
>>> if (x3 == const_int_rtx[MAX_SAVED_CONST_INT + (13)])
>>> goto L9285;
>>> goto ret0;
>>
>> Well, that's coming from here:
>>
>> else
>> printf ("%sx%d = XEXP (x%d, %c);\n",
>> indent, depth + 1, depth, newpos[depth]);
>> ++depth;
>
> Interesting. Looks you have a define_insn which has too many entries.
> It can only have 26 elements, but, annoyingly, genrecog doesn't check
> for that.
>
> It's a bit odd to have more than 26 elements. Do you have any
> incredibly large define_insn patterns?
>
Yes, I have some 80 lines define_insn patterns, are they incredibly large?
>> in the MATCH_OPERAND case of the big switch in add_to_sequence(). Possibly
>> change_state needs to do something like
>>
>> printf ("%sx%d = XEXP (x%d, %d);\n",
>> indent, depth + 1, depth,
>> newpos[depth] > 'a'
>> ? newpos[depth] - 'a'
>> : newpos[depth] - '0');
>
> No, change_state uses upper case and lower case letters to mean
> different things. In this case it's meant to be a lower case letter but
> it has overrun.
>
> This patch should at least cause genrecog to crash for you rather than
> generating bogus output. I've verified that this patch bootstraps on
> x86_64 and makes no difference in the generated insn-recog.c. Can you
> see whether this gives you a crash? Any opinion on whether I should
> commit this to mainline?
>
> Ian
>
>
I try your patch, but it get the same error still.
Dave Korn, thank you all the same.
Re: how can I write a right V32QI Unpack Low Data insn pattern?
Liu writes: >> It's a bit odd to have more than 26 elements. Do you have any >> incredibly large define_insn patterns? >> > Yes, I have some 80 lines define_insn patterns, are they incredibly large? An 80 line pattern is incredibly large, yes. The size of the overall define_insn doesn't matter, just the size of the pattern. > I try your patch, but it get the same error still. Bother. Are you sure that genrecog ran again? Can you send us an example of a very large define_insn pattern? Ian
Re: how can I write a right V32QI Unpack Low Data insn pattern?
On Thu, Mar 3, 2011 at 11:09 AM, Ian Lance Taylor wrote: > Liu writes: > >>> It's a bit odd to have more than 26 elements. Do you have any >>> incredibly large define_insn patterns? >>> >> Yes, I have some 80 lines define_insn patterns, are they incredibly large? > > An 80 line pattern is incredibly large, yes. The size of the overall > define_insn doesn't matter, just the size of the pattern. > >> I try your patch, but it get the same error still. > > Bother. Are you sure that genrecog ran again? Can you send us an > example of a very large define_insn pattern? > > Ian > I'm not sure about "the size of the pattern", I think it is the "const_int" numbers. This is a HADD insn-pattern : (define_insn "xx_vphaddv16hi" [(set (match_operand:V16HI 0 "register_operand" "=Z") (vec_concat:V16HI (vec_concat:V8HI (vec_concat:V4HI (vec_concat:V2HI (plus:HI (vec_select:HI (match_operand:V16HI 1 "register_operand" "Z") (parallel [(const_int 0)])) (vec_select:HI (match_dup 1) (parallel [(const_int 1)]))) (plus:HI (vec_select:HI (match_dup 1) (parallel [(const_int 2)])) (vec_select:HI (match_dup 1) (parallel [(const_int 3)] (vec_concat:V2HI (plus:HI (vec_select:HI (match_dup 1) (parallel [(const_int 4)])) (vec_select:HI (match_dup 1) (parallel [(const_int 5)]))) (plus:HI (vec_select:HI (match_dup 1) (parallel [(const_int 6)])) (vec_select:HI (match_dup 1) (parallel [(const_int 7)]) (vec_concat:V4HI (vec_concat:V2HI (plus:HI (vec_select:HI (match_dup 1) (parallel [(const_int 8)])) (vec_select:HI (match_dup 1) (parallel [(const_int 9)]))) (plus:HI (vec_select:HI (match_dup 1) (parallel [(const_int 10)])) (vec_select:HI (match_dup 1) (parallel [(const_int 11)] (vec_concat:V2HI (plus:HI (vec_select:HI (match_dup 1) (parallel [(const_int 12)])) (vec_select:HI (match_dup 1) (parallel [(const_int 13)]))) (plus:HI (vec_select:HI (match_dup 1) (parallel [(const_int 14)])) (vec_select:HI (match_dup 1) (parallel [(const_int 15)])) (vec_concat:V8HI (vec_concat:V4HI (vec_concat:V2HI (plus:HI (vec_select:HI (match_operand:V16HI 2 "register_operand" "Z") (parallel [(const_int 0)])) (vec_select:HI (match_dup 2) (parallel [(const_int 1)]))) (plus:HI (vec_select:HI (match_dup 2) (parallel [(const_int 2)])) (vec_select:HI (match_dup 2) (parallel [(const_int 3)] (vec_concat:V2HI (plus:HI (vec_select:HI (match_dup 2) (parallel [(const_int 4)])) (vec_select:HI (match_dup 2) (parallel [(const_int 5)]))) (plus:HI (vec_select:HI (match_dup 2) (parallel [(const_int 6)])) (vec_select:HI (match_dup 2) (parallel [(const_int 7)]) (vec_concat:V4HI (vec_concat:V2HI (plus:HI (vec_select:HI (match_dup 2) (parallel [(const_int 8)])) (vec_select:HI (match_dup 2) (parallel [(const_int 9)]))) (plus:HI (vec_select:HI (match_dup 2) (parallel [(const_int 10)])) (vec_select:HI (match_dup 2) (parallel [(const_int 11)] (vec_concat:V2HI (plus:HI (vec_select:HI (match_dup 2) (parallel [(const_int 12)])) (vec_select:HI (match_dup 2) (parallel [(const_int 13)]))) (plus:HI (vec_select:HI (match_dup 2) (parallel [(const_int 14)])) (vec_select:HI (match_dup 2) (parallel [(const_int 15)]] "TARGET_XX_VECTORS" "vphaddh\t%0,%1,%2" [(set_attr "type" "vadd")]) and this is a MADD insn-pattern : (define_insn "xx_vpmaddubsh" [(set (match_operand:V16HI 0 "register_operand" "=Z") (ss_plus:V16HI (mult:V16HI (zero_extend:V16HI (vec_select:V8QI (match_operand:V32QI 1 "register_operand" "Z") (parallel [(const_int 0) (const_int 2) (const_int 4) (const_int 6) (const_int 8) (const_int 10) (const_int 12) (const_int 14) (const_int 16) (const_int 18) (const_int 20) (const_int 22) (const_int 24)
