* 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: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
* 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
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).