* how can I write a right V32QI Unpack Low Data insn pattern?
@ 2011-02-28 23:27 Liu
[not found] ` <mcr1v2rg2lx.fsf@google.com>
0 siblings, 1 reply; 12+ messages in thread
From: Liu @ 2011-02-28 23:27 UTC (permalink / raw)
To: gcc, hellogcc
hi all
I write a v16hi mode Unpack Low Data insn pattern and it is OK. v8si
and v4di modes are OK, too.
But the v32qi mode Unpack Low Data insn pattern get error like:
../../gcc-4.5.1/gcc/config/mips/hr.md:509: error: expected identifier
or ‘(’ before ‘goto’
../../gcc-4.5.1/gcc/config/mips/hr.md:511: error: expected ‘=’, ‘,’,
‘;’, ‘asm’ or ‘__attribute__’ before ‘:’ token
anyone will tell me what's wrong with my code?
;; V16HI Unpack Low Data
(define_insn "vec_punpcklhw"
[(set (match_operand:V16HI 0 "register_operand" "=Z")
(vec_select:V16HI
(vec_concat:V32HI
(match_operand:V16HI 1 "register_operand" "Z")
(match_operand:V16HI 2 "register_operand" "Z"))
(parallel [(const_int 0) (const_int 16)
(const_int 1) (const_int 17)
(const_int 2) (const_int 18)
(const_int 3) (const_int 19)
(const_int 4) (const_int 20)
(const_int 5) (const_int 21)
(const_int 6) (const_int 22)
(const_int 7) (const_int 23)])))]
"TARGET_VECTORS"
"vpunpcklhw\t%0,%1,%2"
[(set_attr "type" "fadd")])
;; V32QI Unpack Low Data
(define_insn "vec_punpcklbh"
[(set (match_operand:V32QI 0 "register_operand" "=Z")
(vec_select:V32QI
(vec_concat:V64QI
(match_operand:V32QI 1 "register_operand" "Z")
(match_operand:V32QI 2 "register_operand" "Z"))
(parallel [(const_int 0) (const_int 32)
(const_int 1) (const_int 33)
(const_int 2) (const_int 34)
(const_int 3) (const_int 35)
(const_int 4) (const_int 36)
(const_int 5) (const_int 37)
(const_int 6) (const_int 38)
(const_int 7) (const_int 39)
(const_int 8) (const_int 40)
(const_int 9) (const_int 41)
(const_int 10) (const_int 42)
(const_int 11) (const_int 43)
(const_int 12) (const_int 44)
(const_int 13) (const_int 45)
(const_int 14) (const_int 46)
(const_int 15) (const_int 47)])))]
"TARGET_VECTORS"
"vpunpcklbh\t%0,%1,%2"
[(set_attr "type" "fadd")])
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: how can I write a right V32QI Unpack Low Data insn pattern?
[not found] ` <mcr1v2rg2lx.fsf@google.com>
@ 2011-03-02 7:57 ` Liu
2011-03-02 14:07 ` Dave Korn
0 siblings, 1 reply; 12+ messages in thread
From: Liu @ 2011-03-02 7:57 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc, hellogcc
On Tue, Mar 1, 2011 at 7:29 AM, Ian Lance Taylor <iant@google.com> wrote:
> Liu <proljc@gmail.com> writes:
>
>> I write a v16hi mode Unpack Low Data insn pattern and it is OK. v8si
>> and v4di modes are OK, too.
>> But the v32qi mode Unpack Low Data insn pattern get error like:
>> ../../gcc-4.5.1/gcc/config/mips/hr.md:509: error: expected identifier
>> or '(' before 'goto'
>> ../../gcc-4.5.1/gcc/config/mips/hr.md:511: error: expected '=', ',',
>> ';', 'asm' or '__attribute__' before ':' token
>> anyone will tell me what's wrong with my code?
>
> Looks like something in a .h file has #define'd something that your .md
> file is using. I can't tell what it is from the code fragment here. If
> it's not obvious, you are going to have to look at the generated file,
> and possibly even the preprocessed version of the generated file.
>
> Ian
>
hi Ian, thank you for reply.
I didn't find something in a.h has #define used by my .md file.
but I find error at insn-recog.c.
When I delete all "#line xxx" in insn-recog.c, compile it as:
gcc -c -g -O0 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition
-Wc++-compat -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.5.1/gcc
-I../../gcc-4.5.1/gcc/. -I../../gcc-4.5.1/gcc/../include
-I../../gcc-4.5.1/gcc/../libcpp/include -I/cross-tools/include
-I/cross-tools/include -I../../gcc-4.5.1/gcc/../libdecnumber
-I../../gcc-4.5.1/gcc/../libdecnumber/dpd -I../libdecnumber
-I/cross-tools/include -I/cross-tools/include -DCLOOG_PPL_BACKEND
insn-recog.c -o insn-recog.o
I get a lot of errors like this:
insn-recog.c: In function 'recog_21':
insn-recog.c:24754: error: expected expression before '{' token
insn-recog.c:24760: error: expected expression before '|' token
insn-recog.c:24766: error: expected expression before '}' token
insn-recog.c:24766: error: expected ')' before '}' token
insn-recog.c:24766: error: expected ')' before '}' token
insn-recog.c:24766: error: expected ';' before '}' token
insn-recog.c:24108: error: label 'ret0' used but not defined
insn-recog.c:24104: error: label 'L9397' used but not defined
insn-recog.c: At top level:
insn-recog.c:24766: error: expected identifier or '(' before ']' token
insn-recog.c:24767: error: expected identifier or '(' before 'if'
insn-recog.c:24769: error: expected identifier or '(' before 'goto'
insn-recog.c:24771: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24773: error: expected identifier or '(' before 'if'
insn-recog.c:24775: error: expected identifier or '(' before 'goto'
insn-recog.c:24777: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24778: error: stray '\177' in program
insn-recog.c:24779: error: expected identifier or '(' before 'if'
insn-recog.c:24781: error: expected identifier or '(' before 'goto'
insn-recog.c:24783: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24784: error: stray '\200' in program
insn-recog.c:24785: error: expected identifier or '(' before 'if'
insn-recog.c:24791: error: expected identifier or '(' before 'goto'
insn-recog.c:24793: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24795: error: expected identifier or '(' before 'if'
insn-recog.c:24797: error: expected identifier or '(' before 'goto'
insn-recog.c:24799: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24809: error: expected identifier or '(' before 'goto'
insn-recog.c:24811: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24813: error: expected identifier or '(' before 'if'
insn-recog.c:24818: error: expected identifier or '(' before 'goto'
insn-recog.c:24820: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24822: error: expected identifier or '(' before 'if'
insn-recog.c:24825: error: expected identifier or '(' before 'goto'
insn-recog.c:24827: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24829: error: expected identifier or '(' before 'if'
insn-recog.c:24834: error: expected identifier or '(' before 'goto'
insn-recog.c:24836: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24842: error: expected identifier or '(' before 'goto'
insn-recog.c:24844: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24846: error: expected identifier or '(' before 'if'
insn-recog.c:24851: error: expected identifier or '(' before 'goto'
insn-recog.c:24853: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24855: error: expected identifier or '(' before 'if'
insn-recog.c:24858: error: expected identifier or '(' before 'goto'
insn-recog.c:24860: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24862: error: expected identifier or '(' before 'if'
insn-recog.c:24867: error: expected identifier or '(' before 'goto'
insn-recog.c:24869: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24875: error: expected identifier or '(' before 'goto'
insn-recog.c:24876: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24878: error: expected identifier or '(' before '}' token
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;
L9288: ATTRIBUTE_UNUSED_LABEL
x3 = XEXP (x2, );
if (x3 == const_int_rtx[MAX_SAVED_CONST_INT + (15)])
goto L9289;
goto ret0;
L9289: ATTRIBUTE_UNUSED_LABEL
x3 = XEXP (x2, );
if (x3 == const_int_rtx[MAX_SAVED_CONST_INT + (47)]
&&
(TARGET_HR_VECTORS))
{
return 1072; /* hr_vpunpcklbh */
}
goto ret0;
It's so weird!
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: how can I write a right V32QI Unpack Low Data insn pattern?
2011-03-02 7:57 ` Liu
@ 2011-03-02 14:07 ` Dave Korn
2011-03-02 15:15 ` Ian Lance Taylor
0 siblings, 1 reply; 12+ messages in thread
From: Dave Korn @ 2011-03-02 14:07 UTC (permalink / raw)
To: Liu; +Cc: Ian Lance Taylor, gcc, hellogcc
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: how can I write a right V32QI Unpack Low Data insn pattern?
2011-03-02 14:07 ` Dave Korn
@ 2011-03-02 15:15 ` Ian Lance Taylor
2011-03-02 15:48 ` Nathan Froyd
` (3 more replies)
0 siblings, 4 replies; 12+ messages in thread
From: Ian Lance Taylor @ 2011-03-02 15:15 UTC (permalink / raw)
To: Dave Korn; +Cc: Liu, gcc, hellogcc
[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]
Dave Korn <dave.korn.cygwin@gmail.com> 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
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 1425 bytes --]
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';
}
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: how can I write a right V32QI Unpack Low Data insn pattern?
2011-03-02 15:15 ` Ian Lance Taylor
@ 2011-03-02 15:48 ` Nathan Froyd
2011-03-02 18:32 ` Ian Lance Taylor
2011-03-02 23:53 ` Richard Henderson
` (2 subsequent siblings)
3 siblings, 1 reply; 12+ messages in thread
From: Nathan Froyd @ 2011-03-02 15:48 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Dave Korn, Liu, gcc, hellogcc
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: how can I write a right V32QI Unpack Low Data insn pattern?
2011-03-02 15:48 ` Nathan Froyd
@ 2011-03-02 18:32 ` Ian Lance Taylor
0 siblings, 0 replies; 12+ messages in thread
From: Ian Lance Taylor @ 2011-03-02 18:32 UTC (permalink / raw)
To: Nathan Froyd; +Cc: Dave Korn, Liu, gcc, hellogcc
Nathan Froyd <froydnj@codesourcery.com> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: how can I write a right V32QI Unpack Low Data insn pattern?
2011-03-02 15:15 ` Ian Lance Taylor
2011-03-02 15:48 ` Nathan Froyd
@ 2011-03-02 23:53 ` Richard Henderson
2011-03-03 2:48 ` Liu
2011-03-03 18:57 ` Dave Korn
3 siblings, 0 replies; 12+ messages in thread
From: Richard Henderson @ 2011-03-02 23:53 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Dave Korn, Liu, gcc, hellogcc
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~
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: how can I write a right V32QI Unpack Low Data insn pattern?
2011-03-02 15:15 ` Ian Lance Taylor
2011-03-02 15:48 ` Nathan Froyd
2011-03-02 23:53 ` Richard Henderson
@ 2011-03-03 2:48 ` Liu
2011-03-03 3:09 ` Ian Lance Taylor
2011-03-03 18:57 ` Dave Korn
3 siblings, 1 reply; 12+ messages in thread
From: Liu @ 2011-03-03 2:48 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Dave Korn, gcc, hellogcc
On Wed, Mar 2, 2011 at 11:14 PM, Ian Lance Taylor <iant@google.com> wrote:
> Dave Korn <dave.korn.cygwin@gmail.com> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: how can I write a right V32QI Unpack Low Data insn pattern?
2011-03-03 2:48 ` Liu
@ 2011-03-03 3:09 ` Ian Lance Taylor
2011-03-03 6:41 ` Liu
2011-03-04 7:20 ` Liu
0 siblings, 2 replies; 12+ messages in thread
From: Ian Lance Taylor @ 2011-03-03 3:09 UTC (permalink / raw)
To: Liu; +Cc: Dave Korn, gcc, hellogcc
Liu <proljc@gmail.com> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: how can I write a right V32QI Unpack Low Data insn pattern?
2011-03-03 3:09 ` Ian Lance Taylor
@ 2011-03-03 6:41 ` Liu
2011-03-04 7:20 ` Liu
1 sibling, 0 replies; 12+ messages in thread
From: Liu @ 2011-03-03 6:41 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Dave Korn, gcc, hellogcc
On Thu, Mar 3, 2011 at 11:09 AM, Ian Lance Taylor <iant@google.com> wrote:
> Liu <proljc@gmail.com> 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)
(const_int 26)
(const_int 28)
(const_int 30)])))
(sign_extend:V16HI
(vec_select:V16QI
(match_operand:V32QI 2 "nonimmediate_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)
(const_int 26)
(const_int 28)
(const_int 30)]))))
(mult:V16HI
(zero_extend:V16HI
(vec_select:V32QI (match_dup 1)
(parallel [(const_int 1)
(const_int 3)
(const_int 5)
(const_int 7)
(const_int 9)
(const_int 11)
(const_int 13)
(const_int 15)
(const_int 17)
(const_int 19)
(const_int 21)
(const_int 23)
(const_int 25)
(const_int 27)
(const_int 29)
(const_int 31)])))
(sign_extend:V16HI
(vec_select:V32QI (match_dup 2)
(parallel [(const_int 1)
(const_int 3)
(const_int 5)
(const_int 7)
(const_int 9)
(const_int 11)
(const_int 13)
(const_int 15)
(const_int 17)
(const_int 19)
(const_int 21)
(const_int 23)
(const_int 25)
(const_int 27)
(const_int 29)
(const_int 31)]))))))]
"TARGET_XX_VECTORS"
"vpmaddubsh\t%0,%1,%2"
[(set_attr "type" "vmin")])
Thank you, Ian.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: how can I write a right V32QI Unpack Low Data insn pattern?
2011-03-02 15:15 ` Ian Lance Taylor
` (2 preceding siblings ...)
2011-03-03 2:48 ` Liu
@ 2011-03-03 18:57 ` Dave Korn
3 siblings, 0 replies; 12+ messages in thread
From: Dave Korn @ 2011-03-03 18:57 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Liu, gcc, hellogcc
On 02/03/2011 15:14, 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?
It's that huge parallel full of (const_int)s that OP quoted at us in the
first post.
cheers,
DaveK
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: how can I write a right V32QI Unpack Low Data insn pattern?
2011-03-03 3:09 ` Ian Lance Taylor
2011-03-03 6:41 ` Liu
@ 2011-03-04 7:20 ` Liu
1 sibling, 0 replies; 12+ messages in thread
From: Liu @ 2011-03-04 7:20 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Dave Korn, gcc, hellogcc
On Thu, Mar 3, 2011 at 11:09 AM, Ian Lance Taylor <iant@google.com> wrote:
> Liu <proljc@gmail.com> 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
>
Oh I get! Your patch made it! Thank you! Ina.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2011-03-04 7:20 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-28 23:27 how can I write a right V32QI Unpack Low Data insn pattern? Liu
[not found] ` <mcr1v2rg2lx.fsf@google.com>
2011-03-02 7:57 ` Liu
2011-03-02 14:07 ` Dave Korn
2011-03-02 15:15 ` Ian Lance Taylor
2011-03-02 15:48 ` Nathan Froyd
2011-03-02 18:32 ` Ian Lance Taylor
2011-03-02 23:53 ` Richard Henderson
2011-03-03 2:48 ` Liu
2011-03-03 3:09 ` Ian Lance Taylor
2011-03-03 6:41 ` Liu
2011-03-04 7:20 ` Liu
2011-03-03 18:57 ` Dave Korn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).