* RE: [patch] extend.texi MIPS PS/3D Support
@ 2004-09-23 18:02 Fu, Chao-Ying
2004-09-24 12:17 ` Dorit Naishlos
0 siblings, 1 reply; 22+ messages in thread
From: Fu, Chao-Ying @ 2004-09-23 18:02 UTC (permalink / raw)
To: Richard Sandiford
Cc: Dorit Naishlos, Giovanni Bajo, gcc-patches, dpatel,
Gerald Pfeifer, Stephens, Nigel, Thekkath, Radhika, Uhler, Mike,
Jim Wilson
I tested one case and got ICE, unfortunately.
Regards,
Chao-ying
---
<540> # cat vect1.c
#define N 16
void fbar (float *);
/* multiple loops */
foo (int n)
{
int i;
float a[N];
float b[N];
/* Vectorizable. */
for (i = 0; i < N; i++){
a[i] = b[i];
}
fbar (a);
}
<541> # mipsisa64-elf-gcc -O2 -mips64 -mpaired-single -ftree-vectorize -fdump-tree-vect-stats -S vect1.c
vect1.c: In function 'foo':
vect1.c:7: internal compiler error: in int_mode_for_mode, at stor-layout.c:251
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
-----Original Message-----
From: gcc-patches-owner@gcc.gnu.org
[mailto:gcc-patches-owner@gcc.gnu.org]On Behalf Of Richard Sandiford
Sent: Thursday, September 23, 2004 9:10 AM
To: Fu, Chao-Ying
Cc: Dorit Naishlos; Giovanni Bajo; gcc-patches@gcc.gnu.org;
dpatel@apple.com; Gerald Pfeifer; Stephens, Nigel; Thekkath, Radhika;
Uhler, Mike; Jim Wilson
Subject: Re: [patch] extend.texi MIPS PS/3D Support
"Fu, Chao-Ying" <fu@mips.com> writes:
> Ok. We need to put this into "mips.h". Thanks!
> [...]
> Index: mips.h
> ===================================================================
> RCS file: /cvsroot/gcc/gcc/gcc/config/mips/mips.h,v
> retrieving revision 1.370
> diff -c -3 -p -r1.370 mips.h
> *** mips.h 18 Sep 2004 19:19:37 -0000 1.370
> --- mips.h 22 Sep 2004 21:07:30 -0000
> *************** extern const struct mips_cpu_info *mips_
> *** 243,248 ****
> --- 243,250 ----
> ((target_flags & MASK_PAIRED_SINGLE) != 0)
> #define TARGET_MIPS3D ((target_flags & MASK_MIPS3D) != 0)
>
> + #define UNITS_PER_SIMD_WORD (TARGET_PAIRED_SINGLE_FLOAT ? 8 : 0)
> +
> /* True if we should use NewABI-style relocation operators for
> symbolic addresses. This is never true for mips16 code,
> which has its own conventions. */
Have you tested this?
Richard
^ permalink raw reply [flat|nested] 22+ messages in thread* RE: [patch] extend.texi MIPS PS/3D Support 2004-09-23 18:02 [patch] extend.texi MIPS PS/3D Support Fu, Chao-Ying @ 2004-09-24 12:17 ` Dorit Naishlos 2004-09-24 21:35 ` Chao-ying Fu 0 siblings, 1 reply; 22+ messages in thread From: Dorit Naishlos @ 2004-09-24 12:17 UTC (permalink / raw) To: Fu, Chao-Ying Cc: dpatel, gcc-patches, Gerald Pfeifer, Giovanni Bajo, Stephens, Nigel, Thekkath, Radhika, Richard Sandiford, Uhler, Mike, Jim Wilson Could you send me some more detail (gdb traceback, what is the mode that's failing in int_mode_for_mode, the .vect dump file when compiling it with -fdump-tree-vect-details)? I can look into it after the weekend (on Sunday). dorit |---------+----------------------------> | | "Fu, Chao-Ying" | | | <fu@mips.com> | | | | | | 23/09/2004 20:17 | |---------+----------------------------> >---------------------------------------------------------------------------------------------------------------| | | | To: "Richard Sandiford" <rsandifo@redhat.com> | | cc: Dorit Naishlos/Haifa/IBM@IBMIL, "Giovanni Bajo" <giovannibajo@libero.it>, | | <gcc-patches@gcc.gnu.org>, <dpatel@apple.com>, "Gerald Pfeifer" <gerald@pfeifer.com>, "Stephens, Nigel"| | <nigel@mercury.mips.com>, "Thekkath, Radhika" <radhika@mercury.mips.com>, "Uhler, Mike" | | <uhler@mercury.mips.com>, "Jim Wilson" <wilson@specifixinc.com> | | Subject: RE: [patch] extend.texi MIPS PS/3D Support | >---------------------------------------------------------------------------------------------------------------| I tested one case and got ICE, unfortunately. Regards, Chao-ying --- <540> # cat vect1.c #define N 16 void fbar (float *); /* multiple loops */ foo (int n) { int i; float a[N]; float b[N]; /* Vectorizable. */ for (i = 0; i < N; i++){ a[i] = b[i]; } fbar (a); } <541> # mipsisa64-elf-gcc -O2 -mips64 -mpaired-single -ftree-vectorize -fdump-tree-vect-stats -S vect1.c vect1.c: In function 'foo': vect1.c:7: internal compiler error: in int_mode_for_mode, at stor-layout.c:251 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. -----Original Message----- From: gcc-patches-owner@gcc.gnu.org [mailto:gcc-patches-owner@gcc.gnu.org]On Behalf Of Richard Sandiford Sent: Thursday, September 23, 2004 9:10 AM To: Fu, Chao-Ying Cc: Dorit Naishlos; Giovanni Bajo; gcc-patches@gcc.gnu.org; dpatel@apple.com; Gerald Pfeifer; Stephens, Nigel; Thekkath, Radhika; Uhler, Mike; Jim Wilson Subject: Re: [patch] extend.texi MIPS PS/3D Support "Fu, Chao-Ying" <fu@mips.com> writes: > Ok. We need to put this into "mips.h". Thanks! > [...] > Index: mips.h > =================================================================== > RCS file: /cvsroot/gcc/gcc/gcc/config/mips/mips.h,v > retrieving revision 1.370 > diff -c -3 -p -r1.370 mips.h > *** mips.h 18 Sep 2004 19:19:37 -0000 1.370 > --- mips.h 22 Sep 2004 21:07:30 -0000 > *************** extern const struct mips_cpu_info *mips_ > *** 243,248 **** > --- 243,250 ---- > ((target_flags & MASK_PAIRED_SINGLE) != 0) > #define TARGET_MIPS3D ((target_flags & MASK_MIPS3D) != 0) > > + #define UNITS_PER_SIMD_WORD (TARGET_PAIRED_SINGLE_FLOAT ? 8 : 0) > + > /* True if we should use NewABI-style relocation operators for > symbolic addresses. This is never true for mips16 code, > which has its own conventions. */ Have you tested this? Richard ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [patch] extend.texi MIPS PS/3D Support 2004-09-24 12:17 ` Dorit Naishlos @ 2004-09-24 21:35 ` Chao-ying Fu 2004-09-25 10:53 ` Richard Sandiford 0 siblings, 1 reply; 22+ messages in thread From: Chao-ying Fu @ 2004-09-24 21:35 UTC (permalink / raw) To: Dorit Naishlos Cc: dpatel, gcc-patches, Gerald Pfeifer, Giovanni Bajo, Stephens, Nigel, Thekkath, Radhika, Richard Sandiford, Uhler, Mike, Jim Wilson Hello, After running "cvs update" and building again today, I can compile the code. But the output assembly is wrong with "<ANYF:loadx> $f0,$9($2)" and "<ANYF:storex> $f0,$8($2)" in it. Thanks! Regards, Chao-ying <67> # cat vect1.c #define N 16 void fbar (float *); float a[N]; float b[N]; /* multiple loops */ foo (int n) { int i; /* Vectorizable. */ for (i = 0; i < N; i++){ a[i] = b[i]; } fbar (a); } <68> # mipsisa64-elf-gcc -O2 -mips64 -mpaired-single -ftree-vectorize -fdump-tree-v ect-stats -S vect1.c <69> # cat vect1.s .file 1 "vect1.c" .section .mdebug.eabi64 .section .gcc_compiled_long64 .previous .text .align 2 .align 3 .globl foo .ent foo foo: .frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0 .mask 0x00000000,0 .fmask 0x00000000,0 .set noreorder .set nomacro lui $4,%hi(a) lui $2,%hi(b) daddiu $9,$2,%lo(b) daddiu $8,$4,%lo(a) move $6,$0 move $5,$0 li $7,8 # 0x8 .align 3 $L2: dsll $2,$5,32 dsrl $2,$2,32 <ANYF:loadx> $f0,$9($2) addiu $3,$6,1 addiu $5,$5,8 <ANYF:storex> $f0,$8($2) bne $7,$3,$L2 move $6,$3 j fbar daddiu $4,$4,%lo(a) .set macro .set reorder .end foo .size foo, .-foo .comm b,64,8 .comm a,64,8 .ident "GCC: (GNU) 4.0.0 20040924 (experimental)" <70> # cat vect1.c.t48.vect ;; Function foo (foo) loop at vect1.c:14: LOOP VECTORIZED. vectorized 1 loops in function. NOTE: no flow-sensitive alias info for vect_pb.2_16 in vect_var_.1_5 = (*vect_pb.2_16)[ivtmp.5_15]; NOTE: no flow-sensitive alias info for vect_pa.6_1 in (*vect_pa.6_1)[ivtmp.9_17] = vect_var_.1_5; DFA Statistics for foo --------------------------------------------------------- Number of Memory instances used --------------------------------------------------------- Referenced variables 15 60b Statements annotated 0 0b Variables annotated 0 0b USE operands 0 0b DEF operands 0 0b VUSE operands 0 0b V_MAY_DEF operands 0 0b V_MUST_DEF operands 0 0b PHI nodes 5 260b PHI arguments 10 120b --------------------------------------------------------- Total memory used by DFA/SSA data 440b --------------------------------------------------------- Average number of arguments per PHI node: 2.0 (max: 2) Hash table statistics: def_blocks: size 31, 2 elements, 0.000000 collision/search ratio DFA Statistics for foo --------------------------------------------------------- Number of Memory instances used --------------------------------------------------------- Referenced variables 15 60b Statements annotated 0 0b Variables annotated 0 0b USE operands 0 0b DEF operands 0 0b VUSE operands 0 0b V_MAY_DEF operands 0 0b V_MUST_DEF operands 0 0b PHI nodes 6 312b PHI arguments 11 132b --------------------------------------------------------- Total memory used by DFA/SSA data 504b --------------------------------------------------------- Average number of arguments per PHI node: 1.8 (max: 2) Hash table statistics: def_blocks: size 31, 1 elements, 0.000000 collision/search ratio foo (n) { int ivtmp.10; int ivtmp.9; float * vect_pa.8; int newinit.7; <unnamed type>[<unknown>] * vect_pa.6; int ivtmp.5; float * vect_pb.4; int newinit.3; <unnamed type>[<unknown>] * vect_pb.2; <unnamed type> vect_var_.1; float b[16]; float a[16]; int i; float D.1169; int i.0; <bb 0>: <L6>:; vect_pb.4_6 = &b[0]; vect_pb.2_16 = (<unnamed type>[<unknown>] *) vect_pb.4_6; vect_pa.8_2 = &a[0]; vect_pa.6_1 = (<unnamed type>[<unknown>] *) vect_pa.8_2; # ivtmp.10_19 = PHI <0(4), ivtmp.10_20(3)>; # ivtmp.9_17 = PHI <0(4), ivtmp.9_18(3)>; # ivtmp.5_15 = PHI <0(4), ivtmp.5_12(3)>; # i_14 = PHI <0(4), i_10(3)>; <L0>:; vect_var_.1_5 = (*vect_pb.2_16)[ivtmp.5_15]; ivtmp.5_12 = ivtmp.5_15 + 1; D.1169_8 = b[i_14]; (*vect_pa.6_1)[ivtmp.9_17] = vect_var_.1_5; ivtmp.9_18 = ivtmp.9_17 + 1; i_10 = i_14 + 1; ivtmp.10_20 = ivtmp.10_19 + 1; if (ivtmp.10_20 < 8) goto <L5>; else goto <L2>; <L5>:; goto <bb 1> (<L0>); <L2>:; fbar (&a); return; } <71> # cat vect1.c.t49.vect ;; Function foo (foo) loop at vect1.c:14: LOOP VECTORIZED. vectorized 1 loops in function. NOTE: no flow-sensitive alias info for vect_pb.2_2 in vect_var_.1_1 = *vect_pb.2_2; NOTE: no flow-sensitive alias info for vect_pa.7_23 in *vect_pa.7_23 = vect_var_.1_1; DFA Statistics for foo --------------------------------------------------------- Number of Memory instances used --------------------------------------------------------- Referenced variables 17 68b Statements annotated 0 0b Variables annotated 0 0b USE operands 0 0b DEF operands 0 0b VUSE operands 0 0b V_MAY_DEF operands 0 0b V_MUST_DEF operands 0 0b PHI nodes 5 260b PHI arguments 10 120b --------------------------------------------------------- Total memory used by DFA/SSA data 448b --------------------------------------------------------- Average number of arguments per PHI node: 2.0 (max: 2) Hash table statistics: def_blocks: size 31, 2 elements, 0.000000 collision/search ratio DFA Statistics for foo --------------------------------------------------------- Number of Memory instances used --------------------------------------------------------- Referenced variables 17 68b Statements annotated 0 0b Variables annotated 0 0b USE operands 0 0b DEF operands 0 0b VUSE operands 0 0b V_MAY_DEF operands 0 0b V_MUST_DEF operands 0 0b PHI nodes 6 312b PHI arguments 11 132b --------------------------------------------------------- Total memory used by DFA/SSA data 512b --------------------------------------------------------- Average number of arguments per PHI node: 1.8 (max: 2) Hash table statistics: def_blocks: size 31, 1 elements, 0.000000 collision/search ratio foo (n) { int ivtmp.12; int update.11; int ivtmp.10; float * vect_pa.9; int newinit.8; <unnamed type> * vect_pa.7; int update.6; int ivtmp.5; float * vect_pb.4; int newinit.3; <unnamed type> * vect_pb.2; <unnamed type> vect_var_.1; int i; float D.1169; int i.0; <bb 0>: <L6>:; vect_pb.4_9 = &b[0]; vect_pb.2_17 = (<unnamed type> *) vect_pb.4_9; vect_pa.9_18 = &a[0]; vect_pa.7_19 = (<unnamed type> *) vect_pa.9_18; # ivtmp.12_24 = PHI <0(4), ivtmp.12_25(3)>; # ivtmp.10_20 = PHI <0(4), ivtmp.10_21(3)>; # ivtmp.5_16 = PHI <0(4), ivtmp.5_13(3)>; # i_15 = PHI <0(4), i_12(3)>; <L0>:; update.6_8 = ivtmp.5_16 * 8; vect_pb.2_2 = update.6_8 + vect_pb.2_17; vect_var_.1_1 = *vect_pb.2_2; ivtmp.5_13 = ivtmp.5_16 + 1; D.1169_10 = b[i_15]; update.11_22 = ivtmp.10_20 * 8; vect_pa.7_23 = vect_pa.7_19 + update.11_22; *vect_pa.7_23 = vect_var_.1_1; ivtmp.10_21 = ivtmp.10_20 + 1; i_12 = i_15 + 1; ivtmp.12_25 = ivtmp.12_24 + 1; if (ivtmp.12_25 < 8) goto <L5>; else goto <L2>; <L5>:; goto <bb 1> (<L0>); <L2>:; fbar (&a); return; } ----- Original Message ----- From: "Dorit Naishlos" <DORIT@il.ibm.com> To: "Fu, Chao-Ying" <fu@mips.com> Cc: <dpatel@apple.com>; <gcc-patches@gcc.gnu.org>; "Gerald Pfeifer" <gerald@pfeifer.com>; "Giovanni Bajo" <giovannibajo@libero.it>; "Stephens, Nigel" <nigel@mercury.mips.com>; "Thekkath, Radhika" <radhika@mercury.mips.com>; "Richard Sandiford" <rsandifo@redhat.com>; "Uhler, Mike" <uhler@mercury.mips.com>; "Jim Wilson" <wilson@specifixinc.com> Sent: Friday, September 24, 2004 2:39 AM Subject: RE: [patch] extend.texi MIPS PS/3D Support > > Could you send me some more detail (gdb traceback, what is the mode that's > failing in int_mode_for_mode, the .vect dump file when compiling it with > -fdump-tree-vect-details)? I can look into it after the weekend (on > Sunday). > > dorit > > > > |---------+----------------------------> > | | "Fu, Chao-Ying" | > | | <fu@mips.com> | > | | | > | | 23/09/2004 20:17 | > |---------+----------------------------> > >--------------------------------------------------------------------------- ------------------------------------| > | | > | To: "Richard Sandiford" <rsandifo@redhat.com> | > | cc: Dorit Naishlos/Haifa/IBM@IBMIL, "Giovanni Bajo" <giovannibajo@libero.it>, | > | <gcc-patches@gcc.gnu.org>, <dpatel@apple.com>, "Gerald Pfeifer" <gerald@pfeifer.com>, "Stephens, Nigel"| > | <nigel@mercury.mips.com>, "Thekkath, Radhika" <radhika@mercury.mips.com>, "Uhler, Mike" | > | <uhler@mercury.mips.com>, "Jim Wilson" <wilson@specifixinc.com> | > | Subject: RE: [patch] extend.texi MIPS PS/3D Support | > >--------------------------------------------------------------------------- ------------------------------------| > > > > > I tested one case and got ICE, unfortunately. > > Regards, > Chao-ying > --- > <540> # cat vect1.c > #define N 16 > > void fbar (float *); > > /* multiple loops */ > foo (int n) > { > int i; > float a[N]; > float b[N]; > > /* Vectorizable. */ > for (i = 0; i < N; i++){ > a[i] = b[i]; > } > > fbar (a); > } > <541> # mipsisa64-elf-gcc -O2 -mips64 -mpaired-single -ftree-vectorize > -fdump-tree-vect-stats -S vect1.c > vect1.c: In function 'foo': > vect1.c:7: internal compiler error: in int_mode_for_mode, at > stor-layout.c:251 > Please submit a full bug report, > with preprocessed source if appropriate. > See <URL:http://gcc.gnu.org/bugs.html> for instructions. > > > -----Original Message----- > From: gcc-patches-owner@gcc.gnu.org > [mailto:gcc-patches-owner@gcc.gnu.org]On Behalf Of Richard Sandiford > Sent: Thursday, September 23, 2004 9:10 AM > To: Fu, Chao-Ying > Cc: Dorit Naishlos; Giovanni Bajo; gcc-patches@gcc.gnu.org; > dpatel@apple.com; Gerald Pfeifer; Stephens, Nigel; Thekkath, Radhika; > Uhler, Mike; Jim Wilson > Subject: Re: [patch] extend.texi MIPS PS/3D Support > > > "Fu, Chao-Ying" <fu@mips.com> writes: > > Ok. We need to put this into "mips.h". Thanks! > > [...] > > Index: mips.h > > =================================================================== > > RCS file: /cvsroot/gcc/gcc/gcc/config/mips/mips.h,v > > retrieving revision 1.370 > > diff -c -3 -p -r1.370 mips.h > > *** mips.h 18 Sep 2004 19:19:37 -0000 1.370 > > --- mips.h 22 Sep 2004 21:07:30 -0000 > > *************** extern const struct mips_cpu_info *mips_ > > *** 243,248 **** > > --- 243,250 ---- > > ((target_flags & > MASK_PAIRED_SINGLE) != 0) > > #define TARGET_MIPS3D ((target_flags & > MASK_MIPS3D) != 0) > > > > + #define UNITS_PER_SIMD_WORD (TARGET_PAIRED_SINGLE_FLOAT ? 8 > : 0) > > + > > /* True if we should use NewABI-style relocation operators for > > symbolic addresses. This is never true for mips16 code, > > which has its own conventions. */ > > Have you tested this? > > Richard > > > > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [patch] extend.texi MIPS PS/3D Support 2004-09-24 21:35 ` Chao-ying Fu @ 2004-09-25 10:53 ` Richard Sandiford 2004-09-27 23:32 ` Chao-ying Fu 0 siblings, 1 reply; 22+ messages in thread From: Richard Sandiford @ 2004-09-25 10:53 UTC (permalink / raw) To: Chao-ying Fu Cc: Dorit Naishlos, dpatel, gcc-patches, Gerald Pfeifer, Giovanni Bajo, Stephens, Nigel, Thekkath, Radhika, Uhler, Mike, Jim Wilson "Chao-ying Fu" <fu@mips.com> writes: > After running "cvs update" and building again today, I can compile the code. > But the output assembly is wrong with > "<ANYF:loadx> $f0,$9($2)" and "<ANYF:storex> $f0,$8($2)" in it. OK, I've checked in the patch below to fix that. Tested by running mips.exp for mipsisa64-elf before and after the patch (which is the only current test of paired-single support). Committed to head. I didn't install a testcase since this would be covered by existing tests once autovectorisation is enabled. WRT defining UNITS_PER_SIMD_WORD: I'd like that patch to go in, but it would need to be run against the vectorisation testsuite first (--target_board mipsisa64-elf/-mpaired-single). Richard * config/mips/mips.md (loadx, storex): Define for V2SF. Index: config/mips/mips.md =================================================================== RCS file: /cvs/gcc/gcc/gcc/config/mips/mips.md,v retrieving revision 1.307 diff -c -p -F^\([(a-zA-Z0-9_]\|#define\) -r1.307 mips.md *** config/mips/mips.md 20 Sep 2004 06:54:52 -0000 1.307 --- config/mips/mips.md 25 Sep 2004 06:32:35 -0000 *************** (define_mode_attr load [(SI "lw") (DI "l *** 355,362 **** (define_mode_attr store [(SI "sw") (DI "sd")]) ;; Similarly for MIPS IV indexed FPR loads and stores. ! (define_mode_attr loadx [(SF "lwxc1") (DF "ldxc1")]) ! (define_mode_attr storex [(SF "swxc1") (DF "sdxc1")]) ;; The unextended ranges of the MIPS16 addiu and daddiu instructions ;; are different. Some forms of unextended addiu have an 8-bit immediate --- 355,362 ---- (define_mode_attr store [(SI "sw") (DI "sd")]) ;; Similarly for MIPS IV indexed FPR loads and stores. ! (define_mode_attr loadx [(SF "lwxc1") (DF "ldxc1") (V2SF "ldxc1")]) ! (define_mode_attr storex [(SF "swxc1") (DF "sdxc1") (V2SF "sdxc1")]) ;; The unextended ranges of the MIPS16 addiu and daddiu instructions ;; are different. Some forms of unextended addiu have an 8-bit immediate ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [patch] extend.texi MIPS PS/3D Support 2004-09-25 10:53 ` Richard Sandiford @ 2004-09-27 23:32 ` Chao-ying Fu 2004-09-28 0:32 ` Dorit Naishlos 0 siblings, 1 reply; 22+ messages in thread From: Chao-ying Fu @ 2004-09-27 23:32 UTC (permalink / raw) To: Dorit Naishlos Cc: Richard Sandiford, Jim Wilson, gcc-patches, Stephens, Nigel, Thekkath, Radhika, Uhler, Mike Hello, One question is as follows. The current MIPS64 architecture doesn't have SIMD integer instructions. But, the vectorizer still vectorized the following C example and generated an incorrect code (daddu $2,$2,$3). How do we disable the vectorization for the integer mode? Thanks! Regards, Chao-ying <122> # cat vect2.c #define N 16 void ibar (int *); int a[N]; int b[N]; int c[N]; /* multiple loops */ foo (int n) { int i; /* Vectorizable. */ for (i = 0; i < N; i++){ a[i] = b[i]+c[i]; } ibar (a); } <123> # mipsisa64-elf-gcc -O2 -mips64 -mpaired-single -ftree-vectorize -fdump-tree-v ect-stats -S vect2.c <124> # cat vect2.s .file 1 "vect2.c" .section .mdebug.eabi64 .section .gcc_compiled_long64 .previous .text .align 2 .align 3 .globl foo .ent foo foo: .frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0 .mask 0x00000000,0 .fmask 0x00000000,0 .set noreorder .set nomacro lui $10,%hi(a) lui $2,%hi(b) lui $3,%hi(c) daddiu $7,$2,%lo(b) daddiu $6,$3,%lo(c) daddiu $5,$10,%lo(a) move $8,$0 li $9,16 # 0x10 .align 3 $L2: ld $2,0($7) ld $3,0($6) addiu $4,$8,1 daddiu $7,$7,8 daddu $2,$2,$3 <-------------------- sd $2,0($5) daddiu $6,$6,8 daddiu $5,$5,8 bne $9,$4,$L2 move $8,$4 j ibar daddiu $4,$10,%lo(a) .set macro .set reorder .end foo .size foo, .-foo .comm c,64,8 .comm b,64,8 .comm a,64,8 .ident "GCC: (GNU) 4.0.0 20040927 (experimental)" <125> # cat vect2.c.t50.vect ;; Function foo (foo) loop at vect2.c:15: LOOP VECTORIZED. vectorized 1 loops in function. NOTE: no flow-sensitive alias info for vect_pb.2_10 in vect_var_.1_2 = *vect_pb.2_10; NOTE: no flow-sensitive alias info for vect_pc.8_27 in vect_var_.7_28 = *vect_pc.8_27; NOTE: no flow-sensitive alias info for vect_pa.14_35 in *vect_pa.14_35 = vect_var_.13_29; DFA Statistics for foo --------------------------------------------------------- Number of Memory instances used --------------------------------------------------------- Referenced variables 27 108b Statements annotated 0 0b Variables annotated 0 0b USE operands 0 0b DEF operands 0 0b VUSE operands 0 0b V_MAY_DEF operands 0 0b V_MUST_DEF operands 0 0b PHI nodes 6 312b PHI arguments 12 144b --------------------------------------------------------- Total memory used by DFA/SSA data 564b --------------------------------------------------------- Average number of arguments per PHI node: 2.0 (max: 2) Hash table statistics: def_blocks: size 31, 3 elements, 0.333333 collision/search ratio DFA Statistics for foo --------------------------------------------------------- Number of Memory instances used --------------------------------------------------------- Referenced variables 27 108b Statements annotated 0 0b Variables annotated 0 0b USE operands 0 0b DEF operands 0 0b VUSE operands 0 0b V_MAY_DEF operands 0 0b V_MUST_DEF operands 0 0b PHI nodes 7 364b PHI arguments 13 156b --------------------------------------------------------- Total memory used by DFA/SSA data 628b --------------------------------------------------------- Average number of arguments per PHI node: 1.9 (max: 2) Hash table statistics: def_blocks: size 61, 1 elements, 0.000000 collision/search ratio foo (n) { int ivtmp.19; int update.18; int ivtmp.17; int * vect_pa.16; int newinit.15; <unnamed type> * vect_pa.14; <unnamed type> vect_var_.13; int update.12; int ivtmp.11; int * vect_pc.10; int newinit.9; <unnamed type> * vect_pc.8; <unnamed type> vect_var_.7; int update.6; int ivtmp.5; int * vect_pb.4; int newinit.3; <unnamed type> * vect_pb.2; <unnamed type> vect_var_.1; int i; int D.1172; int D.1171; int D.1170; int i.0; <bb 0>: <L6>:; vect_pb.4_13 = &b[0]; vect_pb.2_3 = (<unnamed type> *) vect_pb.4_13; vect_pc.10_1 = &c[0]; vect_pc.8_23 = (<unnamed type> *) vect_pc.10_1; vect_pa.16_30 = &a[0]; vect_pa.14_31 = (<unnamed type> *) vect_pa.16_30; # ivtmp.19_36 = PHI <0(4), ivtmp.19_37(3)>; # ivtmp.17_32 = PHI <0(4), ivtmp.17_33(3)>; # ivtmp.11_24 = PHI <0(4), ivtmp.11_25(3)>; # ivtmp.5_22 = PHI <0(4), ivtmp.5_21(3)>; # i_20 = PHI <0(4), i_17(3)>; <L0>:; update.6_18 = ivtmp.5_22 * 8; vect_pb.2_10 = vect_pb.2_3 + update.6_18; vect_var_.1_2 = *vect_pb.2_10; ivtmp.5_21 = ivtmp.5_22 + 1; D.1170_12 = b[i_20]; update.12_26 = ivtmp.11_24 * 8; vect_pc.8_27 = vect_pc.8_23 + update.12_26; vect_var_.7_28 = *vect_pc.8_27; ivtmp.11_25 = ivtmp.11_24 + 1; D.1171_14 = c[i_20]; vect_var_.13_29 = vect_var_.1_2 + vect_var_.7_28; D.1172_15 = D.1170_12 + D.1171_14; update.18_34 = ivtmp.17_32 * 8; vect_pa.14_35 = vect_pa.14_31 + update.18_34; *vect_pa.14_35 = vect_var_.13_29; ivtmp.17_33 = ivtmp.17_32 + 1; i_17 = i_20 + 1; ivtmp.19_37 = ivtmp.19_36 + 1; if (ivtmp.19_37 < 16) goto <L5>; else goto <L2>; <L5>:; goto <bb 1> (<L0>); <L2>:; ibar (&a); return; } ----- Original Message ----- From: "Richard Sandiford" <rsandifo@redhat.com> To: "Chao-ying Fu" <fu@mips.com> Cc: "Dorit Naishlos" <DORIT@il.ibm.com>; <dpatel@apple.com>; <gcc-patches@gcc.gnu.org>; "Gerald Pfeifer" <gerald@pfeifer.com>; "Giovanni Bajo" <giovannibajo@libero.it>; "Stephens, Nigel" <nigel@mercury.mips.com>; "Thekkath, Radhika" <radhika@mercury.mips.com>; "Uhler, Mike" <uhler@mercury.mips.com>; "Jim Wilson" <wilson@specifixinc.com> Sent: Friday, September 24, 2004 11:43 PM Subject: Re: [patch] extend.texi MIPS PS/3D Support > "Chao-ying Fu" <fu@mips.com> writes: > > After running "cvs update" and building again today, I can compile the code. > > But the output assembly is wrong with > > "<ANYF:loadx> $f0,$9($2)" and "<ANYF:storex> $f0,$8($2)" in it. > > OK, I've checked in the patch below to fix that. Tested by running > mips.exp for mipsisa64-elf before and after the patch (which is the > only current test of paired-single support). Committed to head. > I didn't install a testcase since this would be covered by existing > tests once autovectorisation is enabled. > > WRT defining UNITS_PER_SIMD_WORD: I'd like that patch to go in, but > it would need to be run against the vectorisation testsuite first > (--target_board mipsisa64-elf/-mpaired-single). > > Richard > > > * config/mips/mips.md (loadx, storex): Define for V2SF. > > Index: config/mips/mips.md > =================================================================== > RCS file: /cvs/gcc/gcc/gcc/config/mips/mips.md,v > retrieving revision 1.307 > diff -c -p -F^\([(a-zA-Z0-9_]\|#define\) -r1.307 mips.md > *** config/mips/mips.md 20 Sep 2004 06:54:52 -0000 1.307 > --- config/mips/mips.md 25 Sep 2004 06:32:35 -0000 > *************** (define_mode_attr load [(SI "lw") (DI "l > *** 355,362 **** > (define_mode_attr store [(SI "sw") (DI "sd")]) > > ;; Similarly for MIPS IV indexed FPR loads and stores. > ! (define_mode_attr loadx [(SF "lwxc1") (DF "ldxc1")]) > ! (define_mode_attr storex [(SF "swxc1") (DF "sdxc1")]) > > ;; The unextended ranges of the MIPS16 addiu and daddiu instructions > ;; are different. Some forms of unextended addiu have an 8-bit immediate > --- 355,362 ---- > (define_mode_attr store [(SI "sw") (DI "sd")]) > > ;; Similarly for MIPS IV indexed FPR loads and stores. > ! (define_mode_attr loadx [(SF "lwxc1") (DF "ldxc1") (V2SF "ldxc1")]) > ! (define_mode_attr storex [(SF "swxc1") (DF "sdxc1") (V2SF "sdxc1")]) > > ;; The unextended ranges of the MIPS16 addiu and daddiu instructions > ;; are different. Some forms of unextended addiu have an 8-bit immediate > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [patch] extend.texi MIPS PS/3D Support 2004-09-27 23:32 ` Chao-ying Fu @ 2004-09-28 0:32 ` Dorit Naishlos 2004-09-28 0:41 ` Richard Henderson 0 siblings, 1 reply; 22+ messages in thread From: Dorit Naishlos @ 2004-09-28 0:32 UTC (permalink / raw) To: Chao-ying Fu Cc: gcc-patches, Stephens, Nigel, Thekkath, Radhika, Richard Sandiford, Uhler, Mike, Jim Wilson The vectorizer is supposed to fail to vectorize if the relevant machine mode is not supported by the target. If V*SImode is not supported, it should have failed to vectorize here: vectype = get_vectype_for_scalar_type (scalar_type); if (!vectype) { if (vect_debug_stats (loop) || vect_debug_details (loop)) { fprintf (dump_file, "not vectorized: unsupported data-type "); print_generic_expr (dump_file, scalar_type, TDF_SLIM); } return false; } Maybe the problem is here (in get_vectype_for_scalar_type): vectype = build_vector_type (scalar_type, nunits); if (TYPE_MODE (vectype) == BLKmode) return NULL_TREE; Maybe the vectype that is built has a mode other than BLKmode, although it's not supported by the target? (see http://gcc.gnu.org/ml/gcc/2004-09/msg00043.html) -fdump-tree-vect-details may help. dorit |---------+----------------------------> | | "Chao-ying Fu" | | | <fu@mips.com> | | | | | | 28/09/2004 01:08 | | | Please respond to| | | "Chao-ying Fu" | |---------+----------------------------> >---------------------------------------------------------------------------------------------------------------| | | | To: Dorit Naishlos/Haifa/IBM@IBMIL | | cc: "Richard Sandiford" <rsandifo@redhat.com>, "Jim Wilson" <wilson@specifixinc.com>, | | <gcc-patches@gcc.gnu.org>, "Stephens, Nigel" <nigel@mercury.mips.com>, "Thekkath, Radhika" | | <radhika@mercury.mips.com>, "Uhler, Mike" <uhler@mercury.mips.com> | | Subject: Re: [patch] extend.texi MIPS PS/3D Support | >---------------------------------------------------------------------------------------------------------------| Hello, One question is as follows. The current MIPS64 architecture doesn't have SIMD integer instructions. But, the vectorizer still vectorized the following C example and generated an incorrect code (daddu $2,$2,$3). How do we disable the vectorization for the integer mode? Thanks! Regards, Chao-ying <122> # cat vect2.c #define N 16 void ibar (int *); int a[N]; int b[N]; int c[N]; /* multiple loops */ foo (int n) { int i; /* Vectorizable. */ for (i = 0; i < N; i++){ a[i] = b[i]+c[i]; } ibar (a); } <123> # mipsisa64-elf-gcc -O2 -mips64 -mpaired-single -ftree-vectorize -fdump-tree-v ect-stats -S vect2.c <124> # cat vect2.s .file 1 "vect2.c" .section .mdebug.eabi64 .section .gcc_compiled_long64 .previous .text .align 2 .align 3 .globl foo .ent foo foo: .frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0 .mask 0x00000000,0 .fmask 0x00000000,0 .set noreorder .set nomacro lui $10,%hi(a) lui $2,%hi(b) lui $3,%hi(c) daddiu $7,$2,%lo(b) daddiu $6,$3,%lo(c) daddiu $5,$10,%lo(a) move $8,$0 li $9,16 # 0x10 .align 3 $L2: ld $2,0($7) ld $3,0($6) addiu $4,$8,1 daddiu $7,$7,8 daddu $2,$2,$3 <-------------------- sd $2,0($5) daddiu $6,$6,8 daddiu $5,$5,8 bne $9,$4,$L2 move $8,$4 j ibar daddiu $4,$10,%lo(a) .set macro .set reorder .end foo .size foo, .-foo .comm c,64,8 .comm b,64,8 .comm a,64,8 .ident "GCC: (GNU) 4.0.0 20040927 (experimental)" <125> # cat vect2.c.t50.vect ;; Function foo (foo) loop at vect2.c:15: LOOP VECTORIZED. vectorized 1 loops in function. NOTE: no flow-sensitive alias info for vect_pb.2_10 in vect_var_.1_2 = *vect_pb.2_10; NOTE: no flow-sensitive alias info for vect_pc.8_27 in vect_var_.7_28 = *vect_pc.8_27; NOTE: no flow-sensitive alias info for vect_pa.14_35 in *vect_pa.14_35 = vect_var_.13_29; DFA Statistics for foo --------------------------------------------------------- Number of Memory instances used --------------------------------------------------------- Referenced variables 27 108b Statements annotated 0 0b Variables annotated 0 0b USE operands 0 0b DEF operands 0 0b VUSE operands 0 0b V_MAY_DEF operands 0 0b V_MUST_DEF operands 0 0b PHI nodes 6 312b PHI arguments 12 144b --------------------------------------------------------- Total memory used by DFA/SSA data 564b --------------------------------------------------------- Average number of arguments per PHI node: 2.0 (max: 2) Hash table statistics: def_blocks: size 31, 3 elements, 0.333333 collision/search ratio DFA Statistics for foo --------------------------------------------------------- Number of Memory instances used --------------------------------------------------------- Referenced variables 27 108b Statements annotated 0 0b Variables annotated 0 0b USE operands 0 0b DEF operands 0 0b VUSE operands 0 0b V_MAY_DEF operands 0 0b V_MUST_DEF operands 0 0b PHI nodes 7 364b PHI arguments 13 156b --------------------------------------------------------- Total memory used by DFA/SSA data 628b --------------------------------------------------------- Average number of arguments per PHI node: 1.9 (max: 2) Hash table statistics: def_blocks: size 61, 1 elements, 0.000000 collision/search ratio foo (n) { int ivtmp.19; int update.18; int ivtmp.17; int * vect_pa.16; int newinit.15; <unnamed type> * vect_pa.14; <unnamed type> vect_var_.13; int update.12; int ivtmp.11; int * vect_pc.10; int newinit.9; <unnamed type> * vect_pc.8; <unnamed type> vect_var_.7; int update.6; int ivtmp.5; int * vect_pb.4; int newinit.3; <unnamed type> * vect_pb.2; <unnamed type> vect_var_.1; int i; int D.1172; int D.1171; int D.1170; int i.0; <bb 0>: <L6>:; vect_pb.4_13 = &b[0]; vect_pb.2_3 = (<unnamed type> *) vect_pb.4_13; vect_pc.10_1 = &c[0]; vect_pc.8_23 = (<unnamed type> *) vect_pc.10_1; vect_pa.16_30 = &a[0]; vect_pa.14_31 = (<unnamed type> *) vect_pa.16_30; # ivtmp.19_36 = PHI <0(4), ivtmp.19_37(3)>; # ivtmp.17_32 = PHI <0(4), ivtmp.17_33(3)>; # ivtmp.11_24 = PHI <0(4), ivtmp.11_25(3)>; # ivtmp.5_22 = PHI <0(4), ivtmp.5_21(3)>; # i_20 = PHI <0(4), i_17(3)>; <L0>:; update.6_18 = ivtmp.5_22 * 8; vect_pb.2_10 = vect_pb.2_3 + update.6_18; vect_var_.1_2 = *vect_pb.2_10; ivtmp.5_21 = ivtmp.5_22 + 1; D.1170_12 = b[i_20]; update.12_26 = ivtmp.11_24 * 8; vect_pc.8_27 = vect_pc.8_23 + update.12_26; vect_var_.7_28 = *vect_pc.8_27; ivtmp.11_25 = ivtmp.11_24 + 1; D.1171_14 = c[i_20]; vect_var_.13_29 = vect_var_.1_2 + vect_var_.7_28; D.1172_15 = D.1170_12 + D.1171_14; update.18_34 = ivtmp.17_32 * 8; vect_pa.14_35 = vect_pa.14_31 + update.18_34; *vect_pa.14_35 = vect_var_.13_29; ivtmp.17_33 = ivtmp.17_32 + 1; i_17 = i_20 + 1; ivtmp.19_37 = ivtmp.19_36 + 1; if (ivtmp.19_37 < 16) goto <L5>; else goto <L2>; <L5>:; goto <bb 1> (<L0>); <L2>:; ibar (&a); return; } ----- Original Message ----- From: "Richard Sandiford" <rsandifo@redhat.com> To: "Chao-ying Fu" <fu@mips.com> Cc: "Dorit Naishlos" <DORIT@il.ibm.com>; <dpatel@apple.com>; <gcc-patches@gcc.gnu.org>; "Gerald Pfeifer" <gerald@pfeifer.com>; "Giovanni Bajo" <giovannibajo@libero.it>; "Stephens, Nigel" <nigel@mercury.mips.com>; "Thekkath, Radhika" <radhika@mercury.mips.com>; "Uhler, Mike" <uhler@mercury.mips.com>; "Jim Wilson" <wilson@specifixinc.com> Sent: Friday, September 24, 2004 11:43 PM Subject: Re: [patch] extend.texi MIPS PS/3D Support > "Chao-ying Fu" <fu@mips.com> writes: > > After running "cvs update" and building again today, I can compile the code. > > But the output assembly is wrong with > > "<ANYF:loadx> $f0,$9($2)" and "<ANYF:storex> $f0,$8($2)" in it. > > OK, I've checked in the patch below to fix that. Tested by running > mips.exp for mipsisa64-elf before and after the patch (which is the > only current test of paired-single support). Committed to head. > I didn't install a testcase since this would be covered by existing > tests once autovectorisation is enabled. > > WRT defining UNITS_PER_SIMD_WORD: I'd like that patch to go in, but > it would need to be run against the vectorisation testsuite first > (--target_board mipsisa64-elf/-mpaired-single). > > Richard > > > * config/mips/mips.md (loadx, storex): Define for V2SF. > > Index: config/mips/mips.md > =================================================================== > RCS file: /cvs/gcc/gcc/gcc/config/mips/mips.md,v > retrieving revision 1.307 > diff -c -p -F^\([(a-zA-Z0-9_]\|#define\) -r1.307 mips.md > *** config/mips/mips.md 20 Sep 2004 06:54:52 -0000 1.307 > --- config/mips/mips.md 25 Sep 2004 06:32:35 -0000 > *************** (define_mode_attr load [(SI "lw") (DI "l > *** 355,362 **** > (define_mode_attr store [(SI "sw") (DI "sd")]) > > ;; Similarly for MIPS IV indexed FPR loads and stores. > ! (define_mode_attr loadx [(SF "lwxc1") (DF "ldxc1")]) > ! (define_mode_attr storex [(SF "swxc1") (DF "sdxc1")]) > > ;; The unextended ranges of the MIPS16 addiu and daddiu instructions > ;; are different. Some forms of unextended addiu have an 8-bit immediate > --- 355,362 ---- > (define_mode_attr store [(SI "sw") (DI "sd")]) > > ;; Similarly for MIPS IV indexed FPR loads and stores. > ! (define_mode_attr loadx [(SF "lwxc1") (DF "ldxc1") (V2SF "ldxc1")]) > ! (define_mode_attr storex [(SF "swxc1") (DF "sdxc1") (V2SF "sdxc1")]) > > ;; The unextended ranges of the MIPS16 addiu and daddiu instructions > ;; are different. Some forms of unextended addiu have an 8-bit immediate > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [patch] extend.texi MIPS PS/3D Support 2004-09-28 0:32 ` Dorit Naishlos @ 2004-09-28 0:41 ` Richard Henderson 2004-09-28 14:07 ` Dorit Naishlos 0 siblings, 1 reply; 22+ messages in thread From: Richard Henderson @ 2004-09-28 0:41 UTC (permalink / raw) To: Dorit Naishlos Cc: Chao-ying Fu, gcc-patches, Stephens, Nigel, Thekkath, Radhika, Richard Sandiford, Uhler, Mike, Jim Wilson On Tue, Sep 28, 2004 at 01:30:00AM +0200, Dorit Naishlos wrote: > Maybe the problem is here (in get_vectype_for_scalar_type): > > vectype = build_vector_type (scalar_type, nunits); > if (TYPE_MODE (vectype) == BLKmode) > return NULL_TREE; > > Maybe the vectype that is built has a mode other than BLKmode, although > it's not supported by the target? Yes, e.g. V4QI may be represented with SImode. But that's fine, since the vectorizer may be able to optimize data movement loops with no other vector support in the target. (E.g. if target and destination are alignable.) The real problem is that you're pulling out SImode and deciding that add_optab[SImode] is the vector addition operation. r~ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [patch] extend.texi MIPS PS/3D Support 2004-09-28 0:41 ` Richard Henderson @ 2004-09-28 14:07 ` Dorit Naishlos 2004-09-28 14:08 ` Paolo Bonzini ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Dorit Naishlos @ 2004-09-28 14:07 UTC (permalink / raw) To: Richard Henderson Cc: Chao-ying Fu, gcc-patches, Stephens, Nigel, Thekkath, Radhika, Richard Sandiford, Uhler, Mike, Jim Wilson > The real problem is that you're pulling out SImode and deciding > that add_optab[SImode] is the vector addition operation. but how come we get SImode here? we call build_vector_type with innertype = SI, and nunits = UNITS_PER_SIMD_WORD / nbytes = 8 / 4 = 2 so it should return a V2SI vectype, which is not supported by the target and therefore should have a BLKmode. no? dorit Richard Henderson <rth@redhat.com> To: Dorit Naishlos/Haifa/IBM@IBMIL cc: Chao-ying Fu <fu@mips.com>, gcc-patches@gcc.gnu.org, "Stephens, Nigel" 28/09/2004 01:43 <nigel@mercury.mips.com>, "Thekkath, Radhika" <radhika@mercury.mips.com>, Richard Sandiford <rsandifo@redhat.com>, "Uhler, Mike" <uhler@mercury.mips.com>, Jim Wilson <wilson@specifixinc.com> Subject: Re: [patch] extend.texi MIPS PS/3D Support On Tue, Sep 28, 2004 at 01:30:00AM +0200, Dorit Naishlos wrote: > Maybe the problem is here (in get_vectype_for_scalar_type): > > vectype = build_vector_type (scalar_type, nunits); > if (TYPE_MODE (vectype) == BLKmode) > return NULL_TREE; > > Maybe the vectype that is built has a mode other than BLKmode, although > it's not supported by the target? Yes, e.g. V4QI may be represented with SImode. But that's fine, since the vectorizer may be able to optimize data movement loops with no other vector support in the target. (E.g. if target and destination are alignable.) The real problem is that you're pulling out SImode and deciding that add_optab[SImode] is the vector addition operation. r~ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [patch] extend.texi MIPS PS/3D Support 2004-09-28 14:07 ` Dorit Naishlos @ 2004-09-28 14:08 ` Paolo Bonzini 2004-09-29 11:41 ` Paolo Bonzini 2004-09-28 19:35 ` [patch] extend.texi MIPS PS/3D Support Chao-ying Fu 2004-09-28 23:04 ` Richard Henderson 2 siblings, 1 reply; 22+ messages in thread From: Paolo Bonzini @ 2004-09-28 14:08 UTC (permalink / raw) To: Dorit Naishlos Cc: Chao-ying Fu, gcc-patches, Stephens, Nigel, Thekkath, Radhika, Richard Sandiford, Uhler, Mike, Jim Wilson >>The real problem is that you're pulling out SImode and deciding >>that add_optab[SImode] is the vector addition operation. > > but how come we get SImode here? we call build_vector_type with > innertype = SI, and > nunits = UNITS_PER_SIMD_WORD / nbytes = 8 / 4 = 2 > so it should return a V2SI vectype, which is not supported by the target > and therefore should have a BLKmode. no? Yes, it should. Generic vectors should not be created by the vectorizer (yet). Paolo ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [patch] extend.texi MIPS PS/3D Support 2004-09-28 14:08 ` Paolo Bonzini @ 2004-09-29 11:41 ` Paolo Bonzini 2004-09-29 17:33 ` Richard Henderson ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Paolo Bonzini @ 2004-09-29 11:41 UTC (permalink / raw) To: Paolo Bonzini, Richard Henderson, Dorit Naishlos Cc: Chao-ying Fu, gcc-patches, Stephens, Nigel, Thekkath, Radhika, Richard Sandiford, Uhler, Mike, Jim Wilson [-- Attachment #1: Type: text/plain, Size: 545 bytes --] > Yes, it should. Generic vectors should not be created by the vectorizer > (yet). Ah, I thought that the vectorizer created its vector types with a separate routine, but that has been fixed a while ago. The attached patch should help. It was bootstrapped and passes the vectorizer testsuite. Full regtest on i686-pc-linux-gnu is in progress. Ok for mainline? Paolo 2004-09-29 Paolo Bonzini <bonzini@gnu.org> * tree-vectorizer.c (vectorizable_operation): Only look at the optab in the case of vector modes; otherwise, bail out. [-- Attachment #2: fix-vectorizer-generic-types.patch --] [-- Type: text/plain, Size: 934 bytes --] Index: tree-vectorizer.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/tree-vectorizer.c,v retrieving revision 2.12 diff -u -r2.12 tree-vectorizer.c --- tree-vectorizer.c 25 Sep 2004 14:48:03 -0000 2.12 +++ tree-vectorizer.c 29 Sep 2004 07:31:24 -0000 @@ -1408,6 +1408,17 @@ return false; } vec_mode = TYPE_MODE (vectype); + if (GET_MODE_CLASS (vec_mode) != MODE_VECTOR_INT + && GET_MODE_CLASS (vec_mode) != MODE_VECTOR_FLOAT) + { + /* TODO: tree-complex.c sometimes can parallelize operations + on generic vectors. We can vectorize the loop in that case, + but then we should re-run the lowering pass. */ + if (vect_debug_details (NULL)) + fprintf (dump_file, "vector mode not supported by target."); + return false; + } + if (optab->handlers[(int) vec_mode].insn_code == CODE_FOR_nothing) { if (vect_debug_details (NULL)) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [patch] extend.texi MIPS PS/3D Support 2004-09-29 11:41 ` Paolo Bonzini @ 2004-09-29 17:33 ` Richard Henderson 2004-09-29 23:39 ` Dorit Naishlos 2004-10-11 22:48 ` [patch] vectorizer: fix handling of non VECTOR_MODE_P vectypes Dorit Naishlos 2 siblings, 0 replies; 22+ messages in thread From: Richard Henderson @ 2004-09-29 17:33 UTC (permalink / raw) To: Paolo Bonzini Cc: Dorit Naishlos, Chao-ying Fu, gcc-patches, Stephens, Nigel, Thekkath, Radhika, Richard Sandiford, Uhler, Mike, Jim Wilson On Wed, Sep 29, 2004 at 11:17:57AM +0200, Paolo Bonzini wrote: > + if (GET_MODE_CLASS (vec_mode) != MODE_VECTOR_INT > + && GET_MODE_CLASS (vec_mode) != MODE_VECTOR_FLOAT) VECTOR_MODE_P. Otherwise ok. r~ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [patch] extend.texi MIPS PS/3D Support 2004-09-29 11:41 ` Paolo Bonzini 2004-09-29 17:33 ` Richard Henderson @ 2004-09-29 23:39 ` Dorit Naishlos 2004-10-11 22:48 ` [patch] vectorizer: fix handling of non VECTOR_MODE_P vectypes Dorit Naishlos 2 siblings, 0 replies; 22+ messages in thread From: Dorit Naishlos @ 2004-09-29 23:39 UTC (permalink / raw) To: Paolo Bonzini Cc: Paolo Bonzini, Chao-ying Fu, gcc-patches, Stephens, Nigel, Thekkath, Radhika, Richard Sandiford, Richard Henderson, Uhler, Mike, Jim Wilson thanks, Paolo! dorit |---------+----------------------------> | | Paolo Bonzini | | | <bonzini@gnu.org>| | | | | | 29/09/2004 11:17 | |---------+----------------------------> >----------------------------------------------------------------------------------------------------------------------------| | | | To: Paolo Bonzini <bonzini@gnu.org>, Richard Henderson <rth@redhat.com>, Dorit Naishlos/Haifa/IBM@IBMIL | | cc: Chao-ying Fu <fu@mips.com>, gcc-patches@gcc.gnu.org, "Stephens, Nigel" <nigel@mercury.mips.com>, "Thekkath,| | Radhika" <radhika@mercury.mips.com>, Richard Sandiford <rsandifo@redhat.com>, "Uhler, Mike" | | <uhler@mercury.mips.com>, Jim Wilson <wilson@specifixinc.com> | | Subject: Re: [patch] extend.texi MIPS PS/3D Support | >----------------------------------------------------------------------------------------------------------------------------| > Yes, it should. Generic vectors should not be created by the vectorizer > (yet). Ah, I thought that the vectorizer created its vector types with a separate routine, but that has been fixed a while ago. The attached patch should help. It was bootstrapped and passes the vectorizer testsuite. Full regtest on i686-pc-linux-gnu is in progress. Ok for mainline? Paolo 2004-09-29 Paolo Bonzini <bonzini@gnu.org> * tree-vectorizer.c (vectorizable_operation): Only look at the optab in the case of vector modes; otherwise, bail out. Index: tree-vectorizer.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/tree-vectorizer.c,v retrieving revision 2.12 diff -u -r2.12 tree-vectorizer.c --- tree-vectorizer.c 25 Sep 2004 14:48:03 -0000 2.12 +++ tree-vectorizer.c 29 Sep 2004 07:31:24 -0000 @@ -1408,6 +1408,17 @@ return false; } vec_mode = TYPE_MODE (vectype); + if (GET_MODE_CLASS (vec_mode) != MODE_VECTOR_INT + && GET_MODE_CLASS (vec_mode) != MODE_VECTOR_FLOAT) + { + /* TODO: tree-complex.c sometimes can parallelize operations + on generic vectors. We can vectorize the loop in that case, + but then we should re-run the lowering pass. */ + if (vect_debug_details (NULL)) + fprintf (dump_file, "vector mode not supported by target."); + return false; + } + if (optab->handlers[(int) vec_mode].insn_code == CODE_FOR_nothing) { if (vect_debug_details (NULL)) ^ permalink raw reply [flat|nested] 22+ messages in thread
* [patch] vectorizer: fix handling of non VECTOR_MODE_P vectypes 2004-09-29 11:41 ` Paolo Bonzini 2004-09-29 17:33 ` Richard Henderson 2004-09-29 23:39 ` Dorit Naishlos @ 2004-10-11 22:48 ` Dorit Naishlos 2004-10-12 0:40 ` Richard Henderson 2 siblings, 1 reply; 22+ messages in thread From: Dorit Naishlos @ 2004-10-11 22:48 UTC (permalink / raw) To: gcc-patches; +Cc: mark, Richard Henderson [-- Attachment #1: Type: text/plain, Size: 4407 bytes --] > > so it should return a V2SI vectype, which is not supported by the target > > and therefore should have a BLKmode. no? > > Nope. An integer mode is returned if we have one that fits. It > makes the routines in tree-complex.c happy. In this case we also need to fix the computation of the vectorization factor - currently it is set to GET_MODE_NUNITS, which is correct only if the mode is VECTOR_MODE_P. This came up on ppc-darwin compiling SPEC's crafty - build_vector_type returned TImode for a 'long long' type, and the vectorization factor was set to 1 instead of 2. Crafty failed as a result. (Ideally build_vector_type would have returned BLKmode rather than TImode; see machmode.def: "FIXME TI shouldn't be generically available either. *". I didn't fail vectorization in this case, although this type is not really supported and the vectorization will be undone later on). Bootstrapped and tested on ppc-darwin. ok for mainline? thanks, dorit * tree-vectorizer.c (get_vectype_for_scalar_type): Added debug printouts. Added checks under ENABLE_CHECKING to verify the vectorizer's assumptions on the vectype returned by build_vector_type. Check if TImode. (vect_transform_loop): Added gcc_assert under ENABLE_CHECKING. (vect_analyze_operations): Don't use GET_MODE_NUNITS to determine the vectorization factor. Make sure the vectorization factor > 1. Add gcc_assert under ENABLE_CHECKING. (vect_get_vec_def_for_operand): Remove redundant variables. (See attached file: vectfix2) |---------+----------------------------> | | Paolo Bonzini | | | <bonzini@gnu.org>| | | | | | 29/09/2004 11:17 | |---------+----------------------------> >----------------------------------------------------------------------------------------------------------------------------| | | | To: Paolo Bonzini <bonzini@gnu.org>, Richard Henderson <rth@redhat.com>, Dorit Naishlos/Haifa/IBM@IBMIL | | cc: Chao-ying Fu <fu@mips.com>, gcc-patches@gcc.gnu.org, "Stephens, Nigel" <nigel@mercury.mips.com>, "Thekkath,| | Radhika" <radhika@mercury.mips.com>, Richard Sandiford <rsandifo@redhat.com>, "Uhler, Mike" | | <uhler@mercury.mips.com>, Jim Wilson <wilson@specifixinc.com> | | Subject: Re: [patch] extend.texi MIPS PS/3D Support | >----------------------------------------------------------------------------------------------------------------------------| > Yes, it should. Generic vectors should not be created by the vectorizer > (yet). Ah, I thought that the vectorizer created its vector types with a separate routine, but that has been fixed a while ago. The attached patch should help. It was bootstrapped and passes the vectorizer testsuite. Full regtest on i686-pc-linux-gnu is in progress. Ok for mainline? Paolo 2004-09-29 Paolo Bonzini <bonzini@gnu.org> * tree-vectorizer.c (vectorizable_operation): Only look at the optab in the case of vector modes; otherwise, bail out. Index: tree-vectorizer.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/tree-vectorizer.c,v retrieving revision 2.12 diff -u -r2.12 tree-vectorizer.c --- tree-vectorizer.c 25 Sep 2004 14:48:03 -0000 2.12 +++ tree-vectorizer.c 29 Sep 2004 07:31:24 -0000 @@ -1408,6 +1408,17 @@ return false; } vec_mode = TYPE_MODE (vectype); + if (GET_MODE_CLASS (vec_mode) != MODE_VECTOR_INT + && GET_MODE_CLASS (vec_mode) != MODE_VECTOR_FLOAT) + { + /* TODO: tree-complex.c sometimes can parallelize operations + on generic vectors. We can vectorize the loop in that case, + but then we should re-run the lowering pass. */ + if (vect_debug_details (NULL)) + fprintf (dump_file, "vector mode not supported by target."); + return false; + } + if (optab->handlers[(int) vec_mode].insn_code == CODE_FOR_nothing) { if (vect_debug_details (NULL)) [-- Attachment #2: vectfix2 --] [-- Type: application/octet-stream, Size: 7044 bytes --] Index: tree-vectorizer.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/tree-vectorizer.c,v retrieving revision 2.14 diff -c -3 -p -r2.14 tree-vectorizer.c *** tree-vectorizer.c 1 Oct 2004 09:59:00 -0000 2.14 --- tree-vectorizer.c 11 Oct 2004 17:49:35 -0000 *************** static tree *** 836,841 **** --- 836,842 ---- get_vectype_for_scalar_type (tree scalar_type) { enum machine_mode inner_mode = TYPE_MODE (scalar_type); + enum machine_mode vec_mode; int nbytes = GET_MODE_SIZE (inner_mode); int nunits; tree vectype; *************** get_vectype_for_scalar_type (tree scalar *** 848,855 **** nunits = UNITS_PER_SIMD_WORD / nbytes; vectype = build_vector_type (scalar_type, nunits); ! if (TYPE_MODE (vectype) == BLKmode) return NULL_TREE; return vectype; } --- 849,916 ---- nunits = UNITS_PER_SIMD_WORD / nbytes; vectype = build_vector_type (scalar_type, nunits); ! if (vect_debug_details (NULL)) ! { ! fprintf (dump_file, "get vectype with %d units of type ", nunits); ! print_generic_expr (dump_file, scalar_type, TDF_SLIM); ! } ! ! if (!vectype) return NULL_TREE; + + if (vect_debug_details (NULL)) + { + fprintf (dump_file, "vectype: "); + print_generic_expr (dump_file, vectype, TDF_SLIM); + } + + vec_mode = TYPE_MODE (vectype); + + /* Is type supported by target?: */ + if (vec_mode == BLKmode) + { + if (vect_debug_details (NULL)) + fprintf (dump_file, "vectype not supported by target."); + return NULL_TREE; + } + + if (vec_mode == TImode) + { + /* See comment in machmode.def: + "FIXME TI shouldn't be generically available either." + The vectorizer will report that it successfully vectorized, + but this will actually be lowered during RTL expand. */ + if (vect_debug_details (NULL)) + fprintf (dump_file, "TImode; not really supported by target."); + /* return NULL_TREE; */ /* CHECKME */ + } + + #ifdef ENABLE_CHECKING + if (GET_MODE_SIZE (vec_mode) != UNITS_PER_SIMD_WORD) + { + if (vect_debug_details (NULL)) + fprintf (dump_file, "unexpected vectype size."); + return NULL_TREE; + } + + if (VECTOR_MODE_P (vec_mode)) + { + if (nbytes * GET_MODE_NUNITS (vec_mode) != UNITS_PER_SIMD_WORD) + { + if (vect_debug_details (NULL)) + fprintf (dump_file, "unexpected vectype nunits: nunits = %d", + GET_MODE_NUNITS (vec_mode)); + return NULL_TREE; + } + else + if (vect_debug_details (NULL)) + fprintf (dump_file, "supportable vector type."); + } + else + if (vect_debug_details (NULL)) + fprintf (dump_file, "type not really a vector."); + #endif + return vectype; } *************** vect_get_vec_def_for_operand (tree op, t *** 1157,1167 **** /* Create 'vect_cst_ = {cst,cst,...,cst}' */ tree vec_cst; - stmt_vec_info stmt_vinfo = vinfo_for_stmt (stmt); - tree vectype = STMT_VINFO_VECTYPE (stmt_vinfo); - int nunits = GET_MODE_NUNITS (TYPE_MODE (vectype)); - tree t = NULL_TREE; - int i; /* Build a tree with vector elements. */ if (vect_debug_details (NULL)) --- 1218,1223 ---- *************** vect_transform_loop (loop_vec_info loop_ *** 1907,1912 **** --- 1963,1969 ---- bool is_store; #ifdef ENABLE_CHECKING tree vectype; + enum machine_mode vecmode; #endif if (vect_debug_details (NULL)) *************** vect_transform_loop (loop_vec_info loop_ *** 1925,1932 **** /* FORNOW: Verify that all stmts operate on the same number of units and no inner unrolling is necessary. */ vectype = STMT_VINFO_VECTYPE (stmt_info); ! gcc_assert (GET_MODE_NUNITS (TYPE_MODE (vectype)) ! == vectorization_factor); #endif /* -------- vectorize statement ------------ */ if (vect_debug_details (NULL)) --- 1982,1991 ---- /* FORNOW: Verify that all stmts operate on the same number of units and no inner unrolling is necessary. */ vectype = STMT_VINFO_VECTYPE (stmt_info); ! vecmode = TYPE_MODE (vectype); ! gcc_assert (GET_MODE_SIZE (vecmode) == UNITS_PER_SIMD_WORD); ! gcc_assert (GET_MODE_NUNITS (vecmode) == vectorization_factor ! || !VECTOR_MODE_P (vecmode)); #endif /* -------- vectorize statement ------------ */ if (vect_debug_details (NULL)) *************** vect_analyze_operations (loop_vec_info l *** 2044,2050 **** int vectorization_factor = 0; int i; bool ok; - tree scalar_type; if (vect_debug_details (NULL)) fprintf (dump_file, "\n<<vect_analyze_operations>>\n"); --- 2103,2108 ---- *************** vect_analyze_operations (loop_vec_info l *** 2059,2064 **** --- 2117,2124 ---- int nunits; stmt_vec_info stmt_info = vinfo_for_stmt (stmt); tree vectype; + tree scalar_type; + int scalar_size; if (vect_debug_details (NULL)) { *************** vect_analyze_operations (loop_vec_info l *** 2138,2146 **** return false; } ! nunits = GET_MODE_NUNITS (TYPE_MODE (vectype)); ! if (vect_debug_details (NULL)) ! fprintf (dump_file, "nunits = %d", nunits); if (vectorization_factor) { --- 2198,2216 ---- return false; } ! /* Note that: ! (*) GET_MODE_NUNITS (TYPE_MODE (vectype)) == vf ! is not necessarily true! It only holds if the mode of vectype ! is VECTOR_MODE_P. E.g, V4QI may be represented with SI; ! in this case, the LHS is 1, but the vectorization factor (vf) ! should be 4. ! ! We don't require that mode be always VECTOR_TYPE_P because we ! can vectorize such datatypes in some cases (for example, if there ! are only data movements). */ ! ! scalar_size = GET_MODE_SIZE (TYPE_MODE (scalar_type)); ! nunits = UNITS_PER_SIMD_WORD / scalar_size; if (vectorization_factor) { *************** vect_analyze_operations (loop_vec_info l *** 2154,2165 **** } } else ! vectorization_factor = nunits; } } /* TODO: Analyze cost. Decide if worth while to vectorize. */ ! if (!vectorization_factor) { if (vect_debug_stats (loop) || vect_debug_details (loop)) fprintf (dump_file, "not vectorized: unsupported data-type"); --- 2224,2240 ---- } } else ! vectorization_factor = nunits; ! ! #ifdef ENABLE_CHECKING ! gcc_assert (scalar_size * vectorization_factor == UNITS_PER_SIMD_WORD); ! #endif } } /* TODO: Analyze cost. Decide if worth while to vectorize. */ ! ! if (vectorization_factor <= 1) { if (vect_debug_stats (loop) || vect_debug_details (loop)) fprintf (dump_file, "not vectorized: unsupported data-type"); ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [patch] vectorizer: fix handling of non VECTOR_MODE_P vectypes 2004-10-11 22:48 ` [patch] vectorizer: fix handling of non VECTOR_MODE_P vectypes Dorit Naishlos @ 2004-10-12 0:40 ` Richard Henderson 2004-10-12 12:54 ` Dorit Naishlos 0 siblings, 1 reply; 22+ messages in thread From: Richard Henderson @ 2004-10-12 0:40 UTC (permalink / raw) To: Dorit Naishlos; +Cc: gcc-patches, mark On Tue, Oct 12, 2004 at 12:01:20AM +0200, Dorit Naishlos wrote: > (Ideally build_vector_type would have returned BLKmode rather than TImode; > see machmode.def: "FIXME TI shouldn't be generically available either. *". Not ok. You should be checking VECTOR_MODE_P, not some specific integer mode. Didn't this get fixed already, anyway? r~ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [patch] vectorizer: fix handling of non VECTOR_MODE_P vectypes 2004-10-12 0:40 ` Richard Henderson @ 2004-10-12 12:54 ` Dorit Naishlos 2004-10-12 16:37 ` Richard Henderson 2004-10-13 19:18 ` Richard Henderson 0 siblings, 2 replies; 22+ messages in thread From: Dorit Naishlos @ 2004-10-12 12:54 UTC (permalink / raw) To: Richard Henderson; +Cc: gcc-patches, mark [-- Attachment #1: Type: text/plain, Size: 2388 bytes --] > Didn't this get fixed already, anyway? No - the VECTOR_MODE_P check was added only when checking if an operation is supportable. It was not added for loads and stores - to allow vectorization of data movements I thought. Moving the VECTOR_MODE_P check from vectorizable_operation to get_vectype_for_scalar_type would solve the problem. It would be more restrictive (will not allow vectorization of data movement in the case of V4QI represented as SI), but on second thought, the current version is not restrictive enough - it allows initialization with constant/invariants which would not be handled correctly (unless it's an initialization with 0 or -1). I'll use the VECTOR_MODE_P check in all cases (at least for now). Is the following ok? thanks, dorit * tree-vectorizer.c (get_vectype_for_scalar_type): Added debug prinouts. Added check that vectype is VECTOR_MODE_P. (vect_analyze_operations): Make sure the vectorization factor > 1. Add gcc_assert under ENABLE_CHECKING. (vectorizable_operation): Remove check for VECTOR_MODE_P (moved to get_vectype_for_scalar_type). (vect_get_vec_def_for_operand): Remove redundant variables. (vect_transform_loop): Likewise. (See attached file: vectfix3) Richard Henderson <rth@redhat.com> To: Dorit Naishlos/Haifa/IBM@IBMIL cc: gcc-patches@gcc.gnu.org, mark@codesourcery.com 12/10/2004 02:05 Subject: Re: [patch] vectorizer: fix handling of non VECTOR_MODE_P vectypes On Tue, Oct 12, 2004 at 12:01:20AM +0200, Dorit Naishlos wrote: > (Ideally build_vector_type would have returned BLKmode rather than TImode; > see machmode.def: "FIXME TI shouldn't be generically available either. *". Not ok. You should be checking VECTOR_MODE_P, not some specific integer mode. Didn't this get fixed already, anyway? r~ [-- Attachment #2: vectfix3 --] [-- Type: application/octet-stream, Size: 5104 bytes --] Index: tree-vectorizer.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/tree-vectorizer.c,v retrieving revision 2.14 diff -c -3 -p -r2.14 tree-vectorizer.c *** tree-vectorizer.c 1 Oct 2004 09:59:00 -0000 2.14 --- tree-vectorizer.c 12 Oct 2004 08:56:26 -0000 *************** static tree *** 836,841 **** --- 836,842 ---- get_vectype_for_scalar_type (tree scalar_type) { enum machine_mode inner_mode = TYPE_MODE (scalar_type); + enum machine_mode vec_mode; int nbytes = GET_MODE_SIZE (inner_mode); int nunits; tree vectype; *************** get_vectype_for_scalar_type (tree scalar *** 848,855 **** nunits = UNITS_PER_SIMD_WORD / nbytes; vectype = build_vector_type (scalar_type, nunits); ! if (TYPE_MODE (vectype) == BLKmode) return NULL_TREE; return vectype; } --- 849,889 ---- nunits = UNITS_PER_SIMD_WORD / nbytes; vectype = build_vector_type (scalar_type, nunits); ! if (vect_debug_details (NULL)) ! { ! fprintf (dump_file, "get vectype with %d units of type ", nunits); ! print_generic_expr (dump_file, scalar_type, TDF_SLIM); ! } ! ! if (!vectype) return NULL_TREE; + + if (vect_debug_details (NULL)) + { + fprintf (dump_file, "vectype: "); + print_generic_expr (dump_file, vectype, TDF_SLIM); + } + + vec_mode = TYPE_MODE (vectype); + + /* Is type supported by target?: */ + if (vec_mode == BLKmode) + { + if (vect_debug_details (NULL)) + fprintf (dump_file, "vectype not supported by target."); + return NULL_TREE; + } + + if (!VECTOR_MODE_P (vec_mode)) + { + /* TODO: tree-complex.c sometimes can parallelize operations + on generic vectors. We can vectorize the loop in that case, + but then we should re-run the lowering pass. */ + if (vect_debug_details (NULL)) + fprintf (dump_file, "mode not supported by target."); + return NULL_TREE; + } + return vectype; } *************** vect_get_vec_def_for_operand (tree op, t *** 1157,1167 **** /* Create 'vect_cst_ = {cst,cst,...,cst}' */ tree vec_cst; - stmt_vec_info stmt_vinfo = vinfo_for_stmt (stmt); - tree vectype = STMT_VINFO_VECTYPE (stmt_vinfo); - int nunits = GET_MODE_NUNITS (TYPE_MODE (vectype)); - tree t = NULL_TREE; - int i; /* Build a tree with vector elements. */ if (vect_debug_details (NULL)) --- 1191,1196 ---- *************** vectorizable_operation (tree stmt, block *** 1408,1423 **** return false; } vec_mode = TYPE_MODE (vectype); - if (!VECTOR_MODE_P (vec_mode)) - { - /* TODO: tree-complex.c sometimes can parallelize operations - on generic vectors. We can vectorize the loop in that case, - but then we should re-run the lowering pass. */ - if (vect_debug_details (NULL)) - fprintf (dump_file, "mode not supported by target."); - return false; - } - if (optab->handlers[(int) vec_mode].insn_code == CODE_FOR_nothing) { if (vect_debug_details (NULL)) --- 1437,1442 ---- *************** vect_transform_loop (loop_vec_info loop_ *** 1905,1913 **** tree stmt = bsi_stmt (si); stmt_vec_info stmt_info; bool is_store; - #ifdef ENABLE_CHECKING - tree vectype; - #endif if (vect_debug_details (NULL)) { --- 1924,1929 ---- *************** vect_transform_loop (loop_vec_info loop_ *** 1924,1931 **** #ifdef ENABLE_CHECKING /* FORNOW: Verify that all stmts operate on the same number of units and no inner unrolling is necessary. */ ! vectype = STMT_VINFO_VECTYPE (stmt_info); ! gcc_assert (GET_MODE_NUNITS (TYPE_MODE (vectype)) == vectorization_factor); #endif /* -------- vectorize statement ------------ */ --- 1940,1946 ---- #ifdef ENABLE_CHECKING /* FORNOW: Verify that all stmts operate on the same number of units and no inner unrolling is necessary. */ ! gcc_assert (GET_MODE_NUNITS (TYPE_MODE (STMT_VINFO_VECTYPE (stmt_info))) == vectorization_factor); #endif /* -------- vectorize statement ------------ */ *************** vect_analyze_operations (loop_vec_info l *** 2155,2165 **** } else vectorization_factor = nunits; } } /* TODO: Analyze cost. Decide if worth while to vectorize. */ ! if (!vectorization_factor) { if (vect_debug_stats (loop) || vect_debug_details (loop)) fprintf (dump_file, "not vectorized: unsupported data-type"); --- 2170,2186 ---- } else vectorization_factor = nunits; + + #ifdef ENABLE_CHECKING + gcc_assert (GET_MODE_SIZE (TYPE_MODE (scalar_type)) + * vectorization_factor == UNITS_PER_SIMD_WORD); + #endif } } /* TODO: Analyze cost. Decide if worth while to vectorize. */ ! ! if (vectorization_factor <= 1) { if (vect_debug_stats (loop) || vect_debug_details (loop)) fprintf (dump_file, "not vectorized: unsupported data-type"); ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [patch] vectorizer: fix handling of non VECTOR_MODE_P vectypes 2004-10-12 12:54 ` Dorit Naishlos @ 2004-10-12 16:37 ` Richard Henderson 2004-10-12 18:21 ` Dorit Naishlos 2004-10-13 19:18 ` Richard Henderson 1 sibling, 1 reply; 22+ messages in thread From: Richard Henderson @ 2004-10-12 16:37 UTC (permalink / raw) To: Dorit Naishlos; +Cc: gcc-patches, mark On Tue, Oct 12, 2004 at 02:45:50PM +0200, Dorit Naishlos wrote: > ... but on second thought, the current version is not restrictive > enough - it allows initialization with constant/invariants which > would not be handled correctly (unless it's an initialization with > 0 or -1). Test case? r~ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [patch] vectorizer: fix handling of non VECTOR_MODE_P vectypes 2004-10-12 16:37 ` Richard Henderson @ 2004-10-12 18:21 ` Dorit Naishlos 2004-10-12 20:49 ` James A. Morrison 0 siblings, 1 reply; 22+ messages in thread From: Dorit Naishlos @ 2004-10-12 18:21 UTC (permalink / raw) To: Richard Henderson; +Cc: gcc-patches, mark > Test case? Sure: Tests vect-[82,83].c below currently ICE. If compiled in addition with -mpowerpc64 (testcases vect-[82,83]_64.c), then they don't ICE: vect-82_64.c passes ok, and vect-83_64.c produces wrong results. With the patch (that disables vectorization in this case), the tests will pass, but we lose the opportunity to vectorize vect-82_64.c (which may not be so terrible cause we may want to convert this loop to a call to memset instead). dorit ===================================== vect-82.c: /* { dg-do run { target powerpc*-*-* } } */ /* { dg-options "-O2 -ftree-vectorize -fdump-tree-vect-stats -maltivec" { target powerpc*-*-* } } */ #include <stdarg.h> #include "tree-vect.h" #define N 16 int main1 () { long long unsigned int ca[N]; int i; for (i = 0; i < N; i++) ca[i] = 0; /* check results: */ for (i = 0; i < N; i++) { if (ca[i] != 0) abort (); } return 0; } int main (void) { check_vect (); return main1 (); } ===================================== vect-83.c: /* { dg-do run { target powerpc*-*-* } } */ /* { dg-options "-O2 -ftree-vectorize -fdump-tree-vect-stats -maltivec" { target powerpc*-*-* } } */ #include <stdarg.h> #include "tree-vect.h" #define N 16 int main1 () { long long unsigned int ca[N]; int i; for (i = 0; i < N; i++) ca[i] = 2; /* check results: */ for (i = 0; i < N; i++) { if (ca[i] != 2) abort (); } return 0; } int main (void) { check_vect (); return main1 (); } ===================================== vect-82_64.c: /* { dg-do run { target powerpc*-*-* } } */ /* { dg-options "-O2 -ftree-vectorize -mpowerpc64 -fdump-tree-vect-stats -maltivec" { target powerpc*-*-* } } */ #include <stdarg.h> #include "tree-vect.h" #define N 16 int main1 () { long long unsigned int ca[N]; int i; for (i = 0; i < N; i++) ca[i] = 0; /* check results: */ for (i = 0; i < N; i++) { if (ca[i] != 0) abort (); } return 0; } int main (void) { check_vect (); return main1 (); } ===================================== vect-83_64.c: /* { dg-do run { target powerpc*-*-* } } */ /* { dg-options "-O2 -ftree-vectorize -mpowerpc64 -fdump-tree-vect-stats -maltivec" { target powerpc*-*-* } } */ #include <stdarg.h> #include "tree-vect.h" #define N 16 int main1 () { long long unsigned int ca[N]; int i; for (i = 0; i < N; i++) ca[i] = 2; /* check results: */ for (i = 0; i < N; i++) { if (ca[i] != 2) abort (); } return 0; } int main (void) { check_vect (); return main1 (); } ===================================== |---------+----------------------------> | | Richard Henderson| | | <rth@redhat.com> | | | | | | 12/10/2004 18:27 | |---------+----------------------------> >----------------------------------------------------------------------------------------------------------------------------| | | | To: Dorit Naishlos/Haifa/IBM@IBMIL | | cc: gcc-patches@gcc.gnu.org, mark@codesourcery.com | | Subject: Re: [patch] vectorizer: fix handling of non VECTOR_MODE_P vectypes | >----------------------------------------------------------------------------------------------------------------------------| On Tue, Oct 12, 2004 at 02:45:50PM +0200, Dorit Naishlos wrote: > ... but on second thought, the current version is not restrictive > enough - it allows initialization with constant/invariants which > would not be handled correctly (unless it's an initialization with > 0 or -1). Test case? r~ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [patch] vectorizer: fix handling of non VECTOR_MODE_P vectypes 2004-10-12 18:21 ` Dorit Naishlos @ 2004-10-12 20:49 ` James A. Morrison 2004-10-13 8:46 ` Dorit Naishlos 0 siblings, 1 reply; 22+ messages in thread From: James A. Morrison @ 2004-10-12 20:49 UTC (permalink / raw) To: Dorit Naishlos; +Cc: Richard Henderson, gcc-patches, mark Dorit Naishlos <DORIT@il.ibm.com> writes: > > Test case? > > Sure: > > Tests vect-[82,83].c below currently ICE. > If compiled in addition with -mpowerpc64 (testcases vect-[82,83]_64.c), > then they don't ICE: vect-82_64.c passes ok, and vect-83_64.c produces > wrong results. > With the patch (that disables vectorization in this case), the tests will > pass, but we lose the opportunity to vectorize vect-82_64.c (which may not > be so terrible cause we may want to convert this loop to a call to memset > instead). > > dorit > > ===================================== > vect-82.c: > /* { dg-do run { target powerpc*-*-* } } */ > /* { dg-options "-O2 -ftree-vectorize -fdump-tree-vect-stats -maltivec" { > target powerpc*-*-* } } */ This doesn't look right. Why do you need -mpowerpc64? Or even -fdump-tree-vect-stats if this a runtime test? > #include <stdarg.h> > #include "tree-vect.h" > > #define N 16 > > int main1 () > { > long long unsigned int ca[N]; > int i; > > for (i = 0; i < N; i++) > ca[i] = 0; > > /* check results: */ > for (i = 0; i < N; i++) > { > if (ca[i] != 0) > abort (); > } > > return 0; > } > > int main (void) > { > check_vect (); > return main1 (); > } > ===================================== > vect-83.c: > /* { dg-do run { target powerpc*-*-* } } */ > /* { dg-options "-O2 -ftree-vectorize -fdump-tree-vect-stats -maltivec" { > target powerpc*-*-* } } */ > > #include <stdarg.h> > #include "tree-vect.h" > > #define N 16 > > int main1 () > { > long long unsigned int ca[N]; > int i; > > for (i = 0; i < N; i++) > ca[i] = 2; > > /* check results: */ > for (i = 0; i < N; i++) > { > if (ca[i] != 2) > abort (); > } > > return 0; > } > > int main (void) > { > check_vect (); > return main1 (); > } > ===================================== > vect-82_64.c: > /* { dg-do run { target powerpc*-*-* } } */ > /* { dg-options "-O2 -ftree-vectorize -mpowerpc64 -fdump-tree-vect-stats > -maltivec" { target powerpc*-*-* } } */ > > #include <stdarg.h> > #include "tree-vect.h" > > #define N 16 > > int main1 () > { > long long unsigned int ca[N]; > int i; > > for (i = 0; i < N; i++) > ca[i] = 0; > > /* check results: */ > for (i = 0; i < N; i++) > { > if (ca[i] != 0) > abort (); > } > > return 0; > } > > int main (void) > { > check_vect (); > return main1 (); > } > ===================================== > vect-83_64.c: > /* { dg-do run { target powerpc*-*-* } } */ > /* { dg-options "-O2 -ftree-vectorize -mpowerpc64 -fdump-tree-vect-stats > -maltivec" { target powerpc*-*-* } } */ > #include <stdarg.h> > #include "tree-vect.h" > > #define N 16 > > int main1 () > { > long long unsigned int ca[N]; > int i; > > for (i = 0; i < N; i++) > ca[i] = 2; > > /* check results: */ > for (i = 0; i < N; i++) > { > if (ca[i] != 2) > abort (); > } > > return 0; > } > > int main (void) > { > check_vect (); > return main1 (); > } -- Thanks, Jim http://www.student.cs.uwaterloo.ca/~ja2morri/ http://phython.blogspot.com http://open.nit.ca/wiki/?page=jim ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [patch] vectorizer: fix handling of non VECTOR_MODE_P vectypes 2004-10-12 20:49 ` James A. Morrison @ 2004-10-13 8:46 ` Dorit Naishlos 0 siblings, 0 replies; 22+ messages in thread From: Dorit Naishlos @ 2004-10-13 8:46 UTC (permalink / raw) To: James A. Morrison; +Cc: gcc-patches, mark, Richard Henderson > This doesn't look right. Why do you need -mpowerpc64? because I get different failures if I use -mpowerpc64 or not. that's why I have two tests that use -mpowerpc64 and two tests that don't. > Or even > -fdump-tree-vect-stats if this a runtime test? because I also want to verify that nothing got vectorized; so I will also have this at the end of each of these testcases: /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 0 "vect" } } */ dorit ja2morri@csclub.u waterloo.ca To: Dorit Naishlos/Haifa/IBM@IBMIL (James A. cc: Richard Henderson <rth@redhat.com>, gcc-patches@gcc.gnu.org, Morrison) mark@codesourcery.com Subject: Re: [patch] vectorizer: fix handling of non VECTOR_MODE_P 12/10/2004 22:39 vectypes Dorit Naishlos <DORIT@il.ibm.com> writes: > > Test case? > > Sure: > > Tests vect-[82,83].c below currently ICE. > If compiled in addition with -mpowerpc64 (testcases vect-[82,83]_64.c), > then they don't ICE: vect-82_64.c passes ok, and vect-83_64.c produces > wrong results. > With the patch (that disables vectorization in this case), the tests will > pass, but we lose the opportunity to vectorize vect-82_64.c (which may not > be so terrible cause we may want to convert this loop to a call to memset > instead). > > dorit > > ===================================== > vect-82.c: > /* { dg-do run { target powerpc*-*-* } } */ > /* { dg-options "-O2 -ftree-vectorize -fdump-tree-vect-stats -maltivec" { > target powerpc*-*-* } } */ This doesn't look right. Why do you need -mpowerpc64? Or even -fdump-tree-vect-stats if this a runtime test? > #include <stdarg.h> > #include "tree-vect.h" > > #define N 16 > > int main1 () > { > long long unsigned int ca[N]; > int i; > > for (i = 0; i < N; i++) > ca[i] = 0; > > /* check results: */ > for (i = 0; i < N; i++) > { > if (ca[i] != 0) > abort (); > } > > return 0; > } > > int main (void) > { > check_vect (); > return main1 (); > } > ===================================== > vect-83.c: > /* { dg-do run { target powerpc*-*-* } } */ > /* { dg-options "-O2 -ftree-vectorize -fdump-tree-vect-stats -maltivec" { > target powerpc*-*-* } } */ > > #include <stdarg.h> > #include "tree-vect.h" > > #define N 16 > > int main1 () > { > long long unsigned int ca[N]; > int i; > > for (i = 0; i < N; i++) > ca[i] = 2; > > /* check results: */ > for (i = 0; i < N; i++) > { > if (ca[i] != 2) > abort (); > } > > return 0; > } > > int main (void) > { > check_vect (); > return main1 (); > } > ===================================== > vect-82_64.c: > /* { dg-do run { target powerpc*-*-* } } */ > /* { dg-options "-O2 -ftree-vectorize -mpowerpc64 -fdump-tree-vect-stats > -maltivec" { target powerpc*-*-* } } */ > > #include <stdarg.h> > #include "tree-vect.h" > > #define N 16 > > int main1 () > { > long long unsigned int ca[N]; > int i; > > for (i = 0; i < N; i++) > ca[i] = 0; > > /* check results: */ > for (i = 0; i < N; i++) > { > if (ca[i] != 0) > abort (); > } > > return 0; > } > > int main (void) > { > check_vect (); > return main1 (); > } > ===================================== > vect-83_64.c: > /* { dg-do run { target powerpc*-*-* } } */ > /* { dg-options "-O2 -ftree-vectorize -mpowerpc64 -fdump-tree-vect-stats > -maltivec" { target powerpc*-*-* } } */ > #include <stdarg.h> > #include "tree-vect.h" > > #define N 16 > > int main1 () > { > long long unsigned int ca[N]; > int i; > > for (i = 0; i < N; i++) > ca[i] = 2; > > /* check results: */ > for (i = 0; i < N; i++) > { > if (ca[i] != 2) > abort (); > } > > return 0; > } > > int main (void) > { > check_vect (); > return main1 (); > } -- Thanks, Jim http://www.student.cs.uwaterloo.ca/~ja2morri/ http://phython.blogspot.com http://open.nit.ca/wiki/?page=jim ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [patch] vectorizer: fix handling of non VECTOR_MODE_P vectypes 2004-10-12 12:54 ` Dorit Naishlos 2004-10-12 16:37 ` Richard Henderson @ 2004-10-13 19:18 ` Richard Henderson 1 sibling, 0 replies; 22+ messages in thread From: Richard Henderson @ 2004-10-13 19:18 UTC (permalink / raw) To: Dorit Naishlos; +Cc: gcc-patches, mark Ok, except, > + if (vec_mode == BLKmode) This is redundant with > + if (!VECTOR_MODE_P (vec_mode)) This. r~ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [patch] extend.texi MIPS PS/3D Support 2004-09-28 14:07 ` Dorit Naishlos 2004-09-28 14:08 ` Paolo Bonzini @ 2004-09-28 19:35 ` Chao-ying Fu 2004-09-28 23:04 ` Richard Henderson 2 siblings, 0 replies; 22+ messages in thread From: Chao-ying Fu @ 2004-09-28 19:35 UTC (permalink / raw) To: Dorit Naishlos Cc: Richard Henderson, Jim Wilson, gcc-patches, Stephens, Nigel, Thekkath, Radhika, Richard Sandiford, Uhler, Mike Hello, build_vector_type() -> make_vecotr_type() -> layout_type() returns DImode for 2 units of SImode (innermode). Then, vect_analyze_operatoions()->vectorizable_operation() checks if optab->handlers[DImode].insn_code is available. But, we should check optab->handlers[V2SImode].insn_code. Regards, Chao-ying ----- Original Message ----- From: "Dorit Naishlos" <DORIT@il.ibm.com> To: "Richard Henderson" <rth@redhat.com> Cc: "Chao-ying Fu" <fu@mips.com>; <gcc-patches@gcc.gnu.org>; "Stephens, Nigel" <nigel@mercury.mips.com>; "Thekkath, Radhika" <radhika@mercury.mips.com>; "Richard Sandiford" <rsandifo@redhat.com>; "Uhler, Mike" <uhler@mercury.mips.com>; "Jim Wilson" <wilson@specifixinc.com> Sent: Tuesday, September 28, 2004 6:25 AM Subject: Re: [patch] extend.texi MIPS PS/3D Support > > > The real problem is that you're pulling out SImode and deciding > > that add_optab[SImode] is the vector addition operation. > > but how come we get SImode here? we call build_vector_type with > innertype = SI, and > nunits = UNITS_PER_SIMD_WORD / nbytes = 8 / 4 = 2 > so it should return a V2SI vectype, which is not supported by the target > and therefore should have a BLKmode. no? > > dorit > > > > > Richard Henderson > <rth@redhat.com> To: Dorit Naishlos/Haifa/IBM@IBMIL > cc: Chao-ying Fu <fu@mips.com>, gcc-patches@gcc.gnu.org, "Stephens, Nigel" > 28/09/2004 01:43 <nigel@mercury.mips.com>, "Thekkath, Radhika" <radhika@mercury.mips.com>, Richard > Sandiford <rsandifo@redhat.com>, "Uhler, Mike" <uhler@mercury.mips.com>, Jim > Wilson <wilson@specifixinc.com> > Subject: Re: [patch] extend.texi MIPS PS/3D Support > > > > > > On Tue, Sep 28, 2004 at 01:30:00AM +0200, Dorit Naishlos wrote: > > Maybe the problem is here (in get_vectype_for_scalar_type): > > > > vectype = build_vector_type (scalar_type, nunits); > > if (TYPE_MODE (vectype) == BLKmode) > > return NULL_TREE; > > > > Maybe the vectype that is built has a mode other than BLKmode, although > > it's not supported by the target? > > Yes, e.g. V4QI may be represented with SImode. But that's fine, > since the vectorizer may be able to optimize data movement loops > with no other vector support in the target. (E.g. if target and > destination are alignable.) > > The real problem is that you're pulling out SImode and deciding > that add_optab[SImode] is the vector addition operation. > > > r~ > > > > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [patch] extend.texi MIPS PS/3D Support 2004-09-28 14:07 ` Dorit Naishlos 2004-09-28 14:08 ` Paolo Bonzini 2004-09-28 19:35 ` [patch] extend.texi MIPS PS/3D Support Chao-ying Fu @ 2004-09-28 23:04 ` Richard Henderson 2 siblings, 0 replies; 22+ messages in thread From: Richard Henderson @ 2004-09-28 23:04 UTC (permalink / raw) To: Dorit Naishlos Cc: Chao-ying Fu, gcc-patches, Stephens, Nigel, Thekkath, Radhika, Richard Sandiford, Uhler, Mike, Jim Wilson On Tue, Sep 28, 2004 at 03:25:39PM +0200, Dorit Naishlos wrote: > so it should return a V2SI vectype, which is not supported by the target > and therefore should have a BLKmode. no? Nope. An integer mode is returned if we have one that fits. It makes the routines in tree-complex.c happy. r~ ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2004-10-13 19:17 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-09-23 18:02 [patch] extend.texi MIPS PS/3D Support Fu, Chao-Ying 2004-09-24 12:17 ` Dorit Naishlos 2004-09-24 21:35 ` Chao-ying Fu 2004-09-25 10:53 ` Richard Sandiford 2004-09-27 23:32 ` Chao-ying Fu 2004-09-28 0:32 ` Dorit Naishlos 2004-09-28 0:41 ` Richard Henderson 2004-09-28 14:07 ` Dorit Naishlos 2004-09-28 14:08 ` Paolo Bonzini 2004-09-29 11:41 ` Paolo Bonzini 2004-09-29 17:33 ` Richard Henderson 2004-09-29 23:39 ` Dorit Naishlos 2004-10-11 22:48 ` [patch] vectorizer: fix handling of non VECTOR_MODE_P vectypes Dorit Naishlos 2004-10-12 0:40 ` Richard Henderson 2004-10-12 12:54 ` Dorit Naishlos 2004-10-12 16:37 ` Richard Henderson 2004-10-12 18:21 ` Dorit Naishlos 2004-10-12 20:49 ` James A. Morrison 2004-10-13 8:46 ` Dorit Naishlos 2004-10-13 19:18 ` Richard Henderson 2004-09-28 19:35 ` [patch] extend.texi MIPS PS/3D Support Chao-ying Fu 2004-09-28 23:04 ` Richard Henderson
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).