* RFC: PR14880 vec_duplicate or vec_select?
@ 2004-11-06 0:11 Aldy Hernandez
2004-11-06 2:12 ` David Edelsohn
0 siblings, 1 reply; 15+ messages in thread
From: Aldy Hernandez @ 2004-11-06 0:11 UTC (permalink / raw)
To: dje, gcc; +Cc: dorit
Hi David. Hi Dorit.
I'm looking at 14880, and it suggests vecspltX patterns should be modeled
with vec_duplicate, presumably to optimize with the vector optimizer.
I think what we want is vec_select, not vec_duplicate.
Take vspltw for instance:
vspltw v0,v1,3
The specs say, we should put v1[3] into each element of v0.
I think the correct way to model this would be:
(set (reg:V4SI v0)
(vec_select:V4SI (reg:V4SI v1)
(parallel [(const_int 3)
(const_int 3)
(const_int 3)
(const_int 3)])))
What do you guys think? I'm not familiar with the vectorizer, so I don't
know what patterns are actually supported or used.
Let me know, so I can fix the patterns.
Cheers.
Aldy
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RFC: PR14880 vec_duplicate or vec_select?
2004-11-06 0:11 RFC: PR14880 vec_duplicate or vec_select? Aldy Hernandez
@ 2004-11-06 2:12 ` David Edelsohn
2004-11-06 8:42 ` David Edelsohn
2004-11-06 16:58 ` Aldy Hernandez
0 siblings, 2 replies; 15+ messages in thread
From: David Edelsohn @ 2004-11-06 2:12 UTC (permalink / raw)
To: Aldy Hernandez; +Cc: Dorit Naishlos, gcc
The change is not for the auto-vectorizer, it is for GCC's common
vector operation support. GCC cannot assume much about UNSPEC, but can
know about vec_merge, vec_select, vec_concat, vec_duplicate. It is best
to use the standard patterns when available.
The Altivec vspltM (vec_splat) instruction sets each element of
the result to the specified element of the input vector. One could
describe it as selecting the same source vector sub part into each element
of the result (vec_select) or duplicating the 1-element sub-vector into
all elements (vec_duplicate). I am not sure how this should be
canonicalized in GCC or if there already is a preferred form.
David
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RFC: PR14880 vec_duplicate or vec_select?
2004-11-06 2:12 ` David Edelsohn
@ 2004-11-06 8:42 ` David Edelsohn
2004-11-06 16:58 ` Aldy Hernandez
1 sibling, 0 replies; 15+ messages in thread
From: David Edelsohn @ 2004-11-06 8:42 UTC (permalink / raw)
To: Aldy Hernandez; +Cc: Dorit Naishlos, gcc
The change is not for the auto-vectorizer, it is for GCC's common
vector operation support. GCC cannot assume much about UNSPEC, but can
know about vec_merge, vec_select, vec_concat, vec_duplicate. It is best
to use the standard patterns when available.
The Altivec vspltM (vec_splat) instruction sets each element of
the result to the specified element of the input vector. One could
describe it as selecting the same source vector sub part into each element
of the result (vec_select) or duplicating the 1-element sub-vector into
all elements (vec_duplicate). I am not sure how this should be
canonicalized in GCC or if there already is a preferred form.
David
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RFC: PR14880 vec_duplicate or vec_select?
2004-11-06 2:12 ` David Edelsohn
2004-11-06 8:42 ` David Edelsohn
@ 2004-11-06 16:58 ` Aldy Hernandez
2004-11-07 13:15 ` Dorit Naishlos
1 sibling, 1 reply; 15+ messages in thread
From: Aldy Hernandez @ 2004-11-06 16:58 UTC (permalink / raw)
To: David Edelsohn; +Cc: Dorit Naishlos, gcc
> The Altivec vspltM (vec_splat) instruction sets each element of
> the result to the specified element of the input vector. One could
> describe it as selecting the same source vector sub part into each element
> of the result (vec_select) or duplicating the 1-element sub-vector into
> all elements (vec_duplicate). I am not sure how this should be
> canonicalized in GCC or if there already is a preferred form.
Precisely my question. Anyone? Dorit? Once we decide what is the
preferred form, we should update the documentation (which is severely
lacking for vec_* rtl).
BTW, if we should use vec_duplicate, how would you express getting the
1-element sub-vector out? It looks to me like vec_select is appropriate.
BTW2, perhaps I'm not looking hard enough, but I don't see anywhere in
GCC where we're using vec_select or vec_duplicate. Mind you, we must
get away from the unspec's eventually...
Aldy
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RFC: PR14880 vec_duplicate or vec_select?
2004-11-06 16:58 ` Aldy Hernandez
@ 2004-11-07 13:15 ` Dorit Naishlos
2004-11-07 14:28 ` Aldy Hernandez
2004-11-11 21:05 ` Aldy Hernandez
0 siblings, 2 replies; 15+ messages in thread
From: Dorit Naishlos @ 2004-11-07 13:15 UTC (permalink / raw)
To: Aldy Hernandez; +Cc: David Edelsohn, gcc
> > The Altivec vspltM (vec_splat) instruction sets each element
of
> > the result to the specified element of the input vector. One could
> > describe it as selecting the same source vector sub part into each
element
> > of the result (vec_select) or duplicating the 1-element sub-vector into
> > all elements (vec_duplicate). I am not sure how this should be
> > canonicalized in GCC or if there already is a preferred form.
>
> Precisely my question. Anyone? Dorit? Once we decide what is the
> preferred form, we should update the documentation (which is severely
> lacking for vec_* rtl).
the vec_duplicate version seems to be potentially more informative.
> BTW, if we should use vec_duplicate, how would you express getting the
> 1-element sub-vector out? It looks to me like vec_select is appropriate.
how about something like -
(vec_duplicate:V4SI
(vec_select:SI (reg:V4SI v1)
(parallel [(const_int 3)]))
(const_int 4))
?
> BTW2, perhaps I'm not looking hard enough, but I don't see anywhere in
> GCC where we're using vec_select or vec_duplicate. Mind you, we must
> get away from the unspec's eventually...
I found a couple occurrences of VEC_SELECT/VEC_DUPLICATE in simplify-rtx.c,
combine.c.
dorit
Aldy Hernandez
<aldyh@redhat.com To: David Edelsohn <dje@watson.ibm.com>
> cc: Dorit Naishlos/Haifa/IBM@IBMIL, gcc@gcc.gnu.org
Subject: Re: RFC: PR14880 vec_duplicate or vec_select?
06/11/2004 13:00
> The Altivec vspltM (vec_splat) instruction sets each element
of
> the result to the specified element of the input vector. One could
> describe it as selecting the same source vector sub part into each
element
> of the result (vec_select) or duplicating the 1-element sub-vector into
> all elements (vec_duplicate). I am not sure how this should be
> canonicalized in GCC or if there already is a preferred form.
Precisely my question. Anyone? Dorit? Once we decide what is the
preferred form, we should update the documentation (which is severely
lacking for vec_* rtl).
BTW, if we should use vec_duplicate, how would you express getting the
1-element sub-vector out? It looks to me like vec_select is appropriate.
BTW2, perhaps I'm not looking hard enough, but I don't see anywhere in
GCC where we're using vec_select or vec_duplicate. Mind you, we must
get away from the unspec's eventually...
Aldy
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RFC: PR14880 vec_duplicate or vec_select?
2004-11-07 13:15 ` Dorit Naishlos
@ 2004-11-07 14:28 ` Aldy Hernandez
2004-11-11 21:05 ` Aldy Hernandez
1 sibling, 0 replies; 15+ messages in thread
From: Aldy Hernandez @ 2004-11-07 14:28 UTC (permalink / raw)
To: Dorit Naishlos; +Cc: David Edelsohn, gcc
> how about something like -
>
> (vec_duplicate:V4SI
> (vec_select:SI (reg:V4SI v1)
> (parallel [(const_int 3)]))
> (const_int 4))
I don't care either way, but all you folks dealing with vectorization
need to come up with canonical ways of representing all this. Then we
need to document it so every port does the same thing.
I'll wait for anyone else to comment on this by Monday, then I'll
implement the above (or anything y'all agree on).
> > BTW2, perhaps I'm not looking hard enough, but I don't see anywhere in
> > GCC where we're using vec_select or vec_duplicate. Mind you, we must
> > get away from the unspec's eventually...
>
> I found a couple occurrences of VEC_SELECT/VEC_DUPLICATE in simplify-rtx.c,
> combine.c.
Sweet! Thanks.
Aldy
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RFC: PR14880 vec_duplicate or vec_select?
2004-11-07 13:15 ` Dorit Naishlos
2004-11-07 14:28 ` Aldy Hernandez
@ 2004-11-11 21:05 ` Aldy Hernandez
2004-11-14 10:41 ` Dorit Naishlos
1 sibling, 1 reply; 15+ messages in thread
From: Aldy Hernandez @ 2004-11-11 21:05 UTC (permalink / raw)
To: Dorit Naishlos; +Cc: David Edelsohn, gcc
Upon further investigation... I'm seeing all sorts of missing middle
end magic here...
> how about something like -
>
> (vec_duplicate:V4SI
> (vec_select:SI (reg:V4SI v1)
> (parallel [(const_int 3)]))
> (const_int 4))
First, what is the (const_int 4) for? Vec_duplicate only takes one
argument.
Second, and most importantly, the above assumes vec_duplicate can
duplicate scalars.
The documentation is vague, but the argument could be made that it refers
only to input and outputs of vectors.
I know for a fact that the only place that deals with VEC_DUPLICATE
(simplify_unary_operation) specifically outlaws scalars as input:
if (code == VEC_DUPLICATE)
{
gcc_assert (VECTOR_MODE_P (mode));
So...unless y'all decide that VEC_DUPLICATE should handle scalars, we're
back to my other implementation, which will no doubt need further
middle end machinery, but that's a separate issue:
(vec_select:V4SI (reg:V4SI v1)
(parallel [(const_int 3)
(const_int 3)
(const_int 3)
(const_int 3)])))
What do you think? Should VEC_DUPLICATE handle scalars? Could y'all
involved with middle-end vector issues decide?
Cheers.
Aldy
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RFC: PR14880 vec_duplicate or vec_select?
2004-11-11 21:05 ` Aldy Hernandez
@ 2004-11-14 10:41 ` Dorit Naishlos
2004-11-14 12:09 ` Aldy Hernandez
2004-11-14 15:03 ` Aldy Hernandez
0 siblings, 2 replies; 15+ messages in thread
From: Dorit Naishlos @ 2004-11-14 10:41 UTC (permalink / raw)
To: Aldy Hernandez; +Cc: David Edelsohn, gcc
> First, what is the (const_int 4) for? Vec_duplicate only takes one
> argument.
indeed. this extra argument is redundant.
> Second, and most importantly, the above assumes vec_duplicate can
> duplicate scalars.
yes. grepping around I found vec_duplicate used this way in other targets
(sh.md, i386.md).
> What do you think? Should VEC_DUPLICATE handle scalars?
I think it should.
> Could y'all
> involved with middle-end vector issues decide?
as I said before, I prefer the vec_duplicate solution because its more
informative.
dorit
Aldy Hernandez
<aldyh@redhat.com To: Dorit Naishlos/Haifa/IBM@IBMIL
> cc: David Edelsohn <dje@watson.ibm.com>, gcc@gcc.gnu.org
Subject: Re: RFC: PR14880 vec_duplicate or vec_select?
11/11/2004 22:33
Upon further investigation... I'm seeing all sorts of missing middle
end magic here...
> how about something like -
>
> (vec_duplicate:V4SI
> (vec_select:SI (reg:V4SI v1)
> (parallel [(const_int 3)]))
> (const_int 4))
First, what is the (const_int 4) for? Vec_duplicate only takes one
argument.
Second, and most importantly, the above assumes vec_duplicate can
duplicate scalars.
The documentation is vague, but the argument could be made that it refers
only to input and outputs of vectors.
I know for a fact that the only place that deals with VEC_DUPLICATE
(simplify_unary_operation) specifically outlaws scalars as input:
if (code == VEC_DUPLICATE)
{
gcc_assert (VECTOR_MODE_P (mode));
So...unless y'all decide that VEC_DUPLICATE should handle scalars, we're
back to my other implementation, which will no doubt need further
middle end machinery, but that's a separate issue:
(vec_select:V4SI (reg:V4SI v1)
(parallel [(const_int 3)
(const_int 3)
(const_int 3)
(const_int 3)])))
What do you think? Should VEC_DUPLICATE handle scalars? Could y'all
involved with middle-end vector issues decide?
Cheers.
Aldy
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RFC: PR14880 vec_duplicate or vec_select?
2004-11-14 10:41 ` Dorit Naishlos
@ 2004-11-14 12:09 ` Aldy Hernandez
2004-11-14 15:03 ` Aldy Hernandez
1 sibling, 0 replies; 15+ messages in thread
From: Aldy Hernandez @ 2004-11-14 12:09 UTC (permalink / raw)
To: Dorit Naishlos; +Cc: David Edelsohn, gcc
> > Second, and most importantly, the above assumes vec_duplicate can
> > duplicate scalars.
>
> yes. grepping around I found vec_duplicate used this way in other targets
> (sh.md, i386.md).
Ok, I must've triggered a middle end bug then. Will take a look.
> as I said before, I prefer the vec_duplicate solution because its more
> informative.
Aiiiight. Agreed.
Thanks Dorit.
Aldy
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RFC: PR14880 vec_duplicate or vec_select?
2004-11-14 10:41 ` Dorit Naishlos
2004-11-14 12:09 ` Aldy Hernandez
@ 2004-11-14 15:03 ` Aldy Hernandez
2004-11-15 12:39 ` Dorit Naishlos
1 sibling, 1 reply; 15+ messages in thread
From: Aldy Hernandez @ 2004-11-14 15:03 UTC (permalink / raw)
To: Dorit Naishlos; +Cc: David Edelsohn, gcc
Well, since you're awake... :-)
Here is a patch rewriting the patterns. Visual inspection, and manual
testing yields the correct results. The middle-end problem was a typo
on my part, so there's nothing to fix there.
Can you give this a whirl to see if it addresses your concerns?
Thanks.
* config/rs6000/altivec.md ("altivec_vsplth"): Rewrite with
vec_duplicate.
(altivec_vspltb): Same.
(altivec_vspltw): Same.
(altivec_vspltisb): Same.
(altivec_vspltish): Same.
(altivec_vspltisw): Same.
(altivec_vspltisw_v4sf): Same.
(define_constants): Remove UNSPEC_VSPLTISB, UNSPEC_VSPLTISW,
UNSPEC_VSPLTISH.
Move "End of vector xor's" comment to the right place.
Index: config/rs6000/altivec.md
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/altivec.md,v
retrieving revision 1.24
diff -c -p -r1.24 altivec.md
*** config/rs6000/altivec.md 7 Oct 2004 16:05:34 -0000 1.24
--- config/rs6000/altivec.md 14 Nov 2004 12:06:29 -0000
***************
*** 20,29 ****
;; MA 02111-1307, USA.
(define_constants
! [(UNSPEC_VSPLTISW 141)
! (UNSPEC_VSPLTISH 140)
! (UNSPEC_VSPLTISB 139)
! (UNSPEC_VCMPBFP 50)
(UNSPEC_VCMPEQUB 51)
(UNSPEC_VCMPEQUH 52)
(UNSPEC_VCMPEQUW 53)
--- 20,26 ----
;; MA 02111-1307, USA.
(define_constants
! [(UNSPEC_VCMPBFP 50)
(UNSPEC_VCMPEQUB 51)
(UNSPEC_VCMPEQUH 52)
(UNSPEC_VCMPEQUW 53)
***************
*** 1494,1552 ****
"TARGET_ALTIVEC"
"vxor %0,%1,%2"
[(set_attr "type" "vecsimple")])
(define_insn "altivec_vspltb"
[(set (match_operand:V16QI 0 "register_operand" "=v")
! (unspec:V16QI [(match_operand:V16QI 1 "register_operand" "v")
! (match_operand:QI 2 "immediate_operand" "i")] 136))]
"TARGET_ALTIVEC"
"vspltb %0,%1,%2"
[(set_attr "type" "vecperm")])
- ;; End of vector xor's
(define_insn "altivec_vsplth"
[(set (match_operand:V8HI 0 "register_operand" "=v")
! (unspec:V8HI [(match_operand:V8HI 1 "register_operand" "v")
! (match_operand:QI 2 "immediate_operand" "i")] 137))]
"TARGET_ALTIVEC"
"vsplth %0,%1,%2"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltw"
[(set (match_operand:V4SI 0 "register_operand" "=v")
! (unspec:V4SI [(match_operand:V4SI 1 "register_operand" "v")
! (match_operand:QI 2 "immediate_operand" "i")] 138))]
"TARGET_ALTIVEC"
"vspltw %0,%1,%2"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisb"
[(set (match_operand:V16QI 0 "register_operand" "=v")
! (unspec:V16QI [(match_operand:QI 1 "immediate_operand" "i")]
! UNSPEC_VSPLTISB))]
"TARGET_ALTIVEC"
"vspltisb %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltish"
[(set (match_operand:V8HI 0 "register_operand" "=v")
! (unspec:V8HI [(match_operand:QI 1 "immediate_operand" "i")]
! UNSPEC_VSPLTISH))]
"TARGET_ALTIVEC"
"vspltish %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisw"
[(set (match_operand:V4SI 0 "register_operand" "=v")
! (unspec:V4SI [(match_operand:QI 1 "immediate_operand" "i")]
! UNSPEC_VSPLTISW))]
"TARGET_ALTIVEC"
"vspltisw %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisw_v4sf"
[(set (match_operand:V4SF 0 "register_operand" "=v")
! (unspec:V4SF [(match_operand:QI 1 "immediate_operand" "i")] 142))]
"TARGET_ALTIVEC"
"vspltisw %0,%1"
[(set_attr "type" "vecperm")])
--- 1491,1557 ----
"TARGET_ALTIVEC"
"vxor %0,%1,%2"
[(set_attr "type" "vecsimple")])
+ ;; End of vector xor's
(define_insn "altivec_vspltb"
[(set (match_operand:V16QI 0 "register_operand" "=v")
! (vec_duplicate:V16QI
! (vec_select:QI (match_operand:V16QI 1 "register_operand" "v")
! (parallel
! [(match_operand:QI 2 "immediate_operand" "i")]))))]
"TARGET_ALTIVEC"
"vspltb %0,%1,%2"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vsplth"
[(set (match_operand:V8HI 0 "register_operand" "=v")
! (vec_duplicate:V8HI
! (vec_select:HI (match_operand:V8HI 1 "register_operand" "v")
! (parallel
! [(match_operand:HI 2 "immediate_operand" "i")]))))]
"TARGET_ALTIVEC"
"vsplth %0,%1,%2"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltw"
[(set (match_operand:V4SI 0 "register_operand" "=v")
! (vec_duplicate:V4SI
! (vec_select:SI (match_operand:V4SI 1 "register_operand" "v")
! (parallel
! [(match_operand:QI 2 "immediate_operand" "i")]))))]
"TARGET_ALTIVEC"
"vspltw %0,%1,%2"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisb"
[(set (match_operand:V16QI 0 "register_operand" "=v")
! (vec_duplicate:V16QI
! (match_operand:QI 1 "immediate_operand" "i")))]
"TARGET_ALTIVEC"
"vspltisb %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltish"
[(set (match_operand:V8HI 0 "register_operand" "=v")
! (vec_duplicate:V8HI
! (sign_extend:HI (match_operand:QI 1 "immediate_operand" "i"))))]
"TARGET_ALTIVEC"
"vspltish %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisw"
[(set (match_operand:V4SI 0 "register_operand" "=v")
! (vec_duplicate:V4SI
! (sign_extend:SI (match_operand:QI 1 "immediate_operand" "i"))))]
"TARGET_ALTIVEC"
"vspltisw %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisw_v4sf"
[(set (match_operand:V4SF 0 "register_operand" "=v")
! (vec_duplicate:V4SF
! (float:SF (sign_extend:SI
! (match_operand:QI 1 "immediate_operand" "i")))))]
"TARGET_ALTIVEC"
"vspltisw %0,%1"
[(set_attr "type" "vecperm")])
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RFC: PR14880 vec_duplicate or vec_select?
2004-11-14 15:03 ` Aldy Hernandez
@ 2004-11-15 12:39 ` Dorit Naishlos
2004-11-15 13:12 ` Aldy Hernandez
0 siblings, 1 reply; 15+ messages in thread
From: Dorit Naishlos @ 2004-11-15 12:39 UTC (permalink / raw)
To: Aldy Hernandez; +Cc: David Edelsohn, gcc
> Can you give this a whirl
It bootstrapped for me on powerpc-darwin, but I get an ICE if I try to
compile with -maltivec:
gcc -O2 -maltivec vect-2.c
<built-in>:0: internal compiler error: in rs6000_common_init_builtins, at
config/rs6000/rs6000.c:8621
Breakpoint 2, rs6000_common_init_builtins () at
../../gcc/gcc/config/rs6000/rs6000.c:8621
8621 abort ();
(gdb) backtrace
#0 rs6000_common_init_builtins () at
../../gcc/gcc/config/rs6000/rs6000.c:8621
#1 0x003560ac in rs6000_common_init_builtins () at
../../gcc/gcc/config/rs6000/rs6000.c:8623
#2 0x00047ff8 in c_common_nodes_and_builtins () at
../../gcc/gcc/c-common.c:3229
#3 0x0001089c in c_init_decl_processing () at ../../gcc/gcc/c-decl.c:2564
#4 0x00058d48 in c_objc_common_init () at
../../gcc/gcc/c-objc-common.c:163
#5 0x00319804 in toplev_main (argc=6422528, argv=0x20000000) at
../../gcc/gcc/toplev.c:1972
#6 0x00002338 in _start (argc=6634700, argv=0x6268cc, envp=0x620000) at
/SourceCache/Csu/Csu-46/crt.c:267
#7 0x000021ac in start () at ../../gcc/libiberty/cp-demangle.c:651
(gdb)
dorit
|---------+---------------------------->
| | Aldy Hernandez |
| | <aldyh@redhat.com|
| | > |
| | |
| | 14/11/2004 14:09 |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------|
| |
| To: Dorit Naishlos/Haifa/IBM@IBMIL |
| cc: David Edelsohn <dje@watson.ibm.com>, gcc@gcc.gnu.org |
| Subject: Re: RFC: PR14880 vec_duplicate or vec_select? |
>------------------------------------------------------------------------------------------------------------------------|
Well, since you're awake... :-)
Here is a patch rewriting the patterns. Visual inspection, and manual
testing yields the correct results. The middle-end problem was a typo
on my part, so there's nothing to fix there.
Can you give this a whirl to see if it addresses your concerns?
Thanks.
* config/rs6000/altivec.md ("altivec_vsplth"): Rewrite with
vec_duplicate.
(altivec_vspltb): Same.
(altivec_vspltw): Same.
(altivec_vspltisb): Same.
(altivec_vspltish): Same.
(altivec_vspltisw): Same.
(altivec_vspltisw_v4sf): Same.
(define_constants): Remove UNSPEC_VSPLTISB, UNSPEC_VSPLTISW,
UNSPEC_VSPLTISH.
Move "End of vector xor's" comment to the right place.
Index: config/rs6000/altivec.md
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/altivec.md,v
retrieving revision 1.24
diff -c -p -r1.24 altivec.md
*** config/rs6000/altivec.md 7 Oct 2004 16:05:34 -0000
1.24
--- config/rs6000/altivec.md 14 Nov 2004 12:06:29 -0000
***************
*** 20,29 ****
;; MA 02111-1307, USA.
(define_constants
! [(UNSPEC_VSPLTISW 141)
! (UNSPEC_VSPLTISH 140)
! (UNSPEC_VSPLTISB 139)
! (UNSPEC_VCMPBFP 50)
(UNSPEC_VCMPEQUB 51)
(UNSPEC_VCMPEQUH 52)
(UNSPEC_VCMPEQUW 53)
--- 20,26 ----
;; MA 02111-1307, USA.
(define_constants
! [(UNSPEC_VCMPBFP 50)
(UNSPEC_VCMPEQUB 51)
(UNSPEC_VCMPEQUH 52)
(UNSPEC_VCMPEQUW 53)
***************
*** 1494,1552 ****
"TARGET_ALTIVEC"
"vxor %0,%1,%2"
[(set_attr "type" "vecsimple")])
(define_insn "altivec_vspltb"
[(set (match_operand:V16QI 0 "register_operand" "=v")
! (unspec:V16QI [(match_operand:V16QI 1 "register_operand" "v")
! (match_operand:QI 2 "immediate_operand" "i")]
136))]
"TARGET_ALTIVEC"
"vspltb %0,%1,%2"
[(set_attr "type" "vecperm")])
- ;; End of vector xor's
(define_insn "altivec_vsplth"
[(set (match_operand:V8HI 0 "register_operand" "=v")
! (unspec:V8HI [(match_operand:V8HI 1 "register_operand" "v")
! (match_operand:QI 2 "immediate_operand" "i")]
137))]
"TARGET_ALTIVEC"
"vsplth %0,%1,%2"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltw"
[(set (match_operand:V4SI 0 "register_operand" "=v")
! (unspec:V4SI [(match_operand:V4SI 1 "register_operand" "v")
! (match_operand:QI 2 "immediate_operand" "i")]
138))]
"TARGET_ALTIVEC"
"vspltw %0,%1,%2"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisb"
[(set (match_operand:V16QI 0 "register_operand" "=v")
! (unspec:V16QI [(match_operand:QI 1 "immediate_operand" "i")]
! UNSPEC_VSPLTISB))]
"TARGET_ALTIVEC"
"vspltisb %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltish"
[(set (match_operand:V8HI 0 "register_operand" "=v")
! (unspec:V8HI [(match_operand:QI 1 "immediate_operand" "i")]
! UNSPEC_VSPLTISH))]
"TARGET_ALTIVEC"
"vspltish %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisw"
[(set (match_operand:V4SI 0 "register_operand" "=v")
! (unspec:V4SI [(match_operand:QI 1 "immediate_operand" "i")]
! UNSPEC_VSPLTISW))]
"TARGET_ALTIVEC"
"vspltisw %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisw_v4sf"
[(set (match_operand:V4SF 0 "register_operand" "=v")
! (unspec:V4SF [(match_operand:QI 1 "immediate_operand" "i")]
142))]
"TARGET_ALTIVEC"
"vspltisw %0,%1"
[(set_attr "type" "vecperm")])
--- 1491,1557 ----
"TARGET_ALTIVEC"
"vxor %0,%1,%2"
[(set_attr "type" "vecsimple")])
+ ;; End of vector xor's
(define_insn "altivec_vspltb"
[(set (match_operand:V16QI 0 "register_operand" "=v")
! (vec_duplicate:V16QI
! (vec_select:QI (match_operand:V16QI 1 "register_operand" "v")
! (parallel
! [(match_operand:QI 2
"immediate_operand" "i")]))))]
"TARGET_ALTIVEC"
"vspltb %0,%1,%2"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vsplth"
[(set (match_operand:V8HI 0 "register_operand" "=v")
! (vec_duplicate:V8HI
! (vec_select:HI (match_operand:V8HI 1 "register_operand" "v")
! (parallel
! [(match_operand:HI 2
"immediate_operand" "i")]))))]
"TARGET_ALTIVEC"
"vsplth %0,%1,%2"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltw"
[(set (match_operand:V4SI 0 "register_operand" "=v")
! (vec_duplicate:V4SI
! (vec_select:SI (match_operand:V4SI 1 "register_operand" "v")
! (parallel
! [(match_operand:QI 2
"immediate_operand" "i")]))))]
"TARGET_ALTIVEC"
"vspltw %0,%1,%2"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisb"
[(set (match_operand:V16QI 0 "register_operand" "=v")
! (vec_duplicate:V16QI
! (match_operand:QI 1 "immediate_operand" "i")))]
"TARGET_ALTIVEC"
"vspltisb %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltish"
[(set (match_operand:V8HI 0 "register_operand" "=v")
! (vec_duplicate:V8HI
! (sign_extend:HI (match_operand:QI 1 "immediate_operand"
"i"))))]
"TARGET_ALTIVEC"
"vspltish %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisw"
[(set (match_operand:V4SI 0 "register_operand" "=v")
! (vec_duplicate:V4SI
! (sign_extend:SI (match_operand:QI 1 "immediate_operand"
"i"))))]
"TARGET_ALTIVEC"
"vspltisw %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisw_v4sf"
[(set (match_operand:V4SF 0 "register_operand" "=v")
! (vec_duplicate:V4SF
! (float:SF (sign_extend:SI
! (match_operand:QI 1 "immediate_operand"
"i")))))]
"TARGET_ALTIVEC"
"vspltisw %0,%1"
[(set_attr "type" "vecperm")])
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RFC: PR14880 vec_duplicate or vec_select?
2004-11-15 12:39 ` Dorit Naishlos
@ 2004-11-15 13:12 ` Aldy Hernandez
2004-11-15 20:04 ` Dorit Naishlos
0 siblings, 1 reply; 15+ messages in thread
From: Aldy Hernandez @ 2004-11-15 13:12 UTC (permalink / raw)
To: Dorit Naishlos; +Cc: David Edelsohn, gcc
> It bootstrapped for me on powerpc-darwin, but I get an ICE if I try to
> compile with -maltivec:
Whoops. Typo. Arghhh... I need to get my AltiVec box back.
Try this.
Thanks.
Aldy
* config/rs6000/altivec.md ("altivec_vsplth"): Rewrite with
vec_duplicate.
(altivec_vspltb): Same.
(altivec_vspltw): Same.
(altivec_vspltisb): Same.
(altivec_vspltish): Same.
(altivec_vspltisw): Same.
(altivec_vspltisw_v4sf): Same.
(define_constants): Remove UNSPEC_VSPLTISB, UNSPEC_VSPLTISW,
UNSPEC_VSPLTISH.
Move "End of vector xor's" comment to the right place.
Index: config/rs6000/altivec.md
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/altivec.md,v
retrieving revision 1.24
diff -c -p -r1.24 altivec.md
*** config/rs6000/altivec.md 7 Oct 2004 16:05:34 -0000 1.24
--- config/rs6000/altivec.md 15 Nov 2004 12:37:14 -0000
***************
*** 20,29 ****
;; MA 02111-1307, USA.
(define_constants
! [(UNSPEC_VSPLTISW 141)
! (UNSPEC_VSPLTISH 140)
! (UNSPEC_VSPLTISB 139)
! (UNSPEC_VCMPBFP 50)
(UNSPEC_VCMPEQUB 51)
(UNSPEC_VCMPEQUH 52)
(UNSPEC_VCMPEQUW 53)
--- 20,26 ----
;; MA 02111-1307, USA.
(define_constants
! [(UNSPEC_VCMPBFP 50)
(UNSPEC_VCMPEQUB 51)
(UNSPEC_VCMPEQUH 52)
(UNSPEC_VCMPEQUW 53)
***************
*** 1494,1552 ****
"TARGET_ALTIVEC"
"vxor %0,%1,%2"
[(set_attr "type" "vecsimple")])
(define_insn "altivec_vspltb"
[(set (match_operand:V16QI 0 "register_operand" "=v")
! (unspec:V16QI [(match_operand:V16QI 1 "register_operand" "v")
! (match_operand:QI 2 "immediate_operand" "i")] 136))]
"TARGET_ALTIVEC"
"vspltb %0,%1,%2"
[(set_attr "type" "vecperm")])
- ;; End of vector xor's
(define_insn "altivec_vsplth"
[(set (match_operand:V8HI 0 "register_operand" "=v")
! (unspec:V8HI [(match_operand:V8HI 1 "register_operand" "v")
! (match_operand:QI 2 "immediate_operand" "i")] 137))]
"TARGET_ALTIVEC"
"vsplth %0,%1,%2"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltw"
[(set (match_operand:V4SI 0 "register_operand" "=v")
! (unspec:V4SI [(match_operand:V4SI 1 "register_operand" "v")
! (match_operand:QI 2 "immediate_operand" "i")] 138))]
"TARGET_ALTIVEC"
"vspltw %0,%1,%2"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisb"
[(set (match_operand:V16QI 0 "register_operand" "=v")
! (unspec:V16QI [(match_operand:QI 1 "immediate_operand" "i")]
! UNSPEC_VSPLTISB))]
"TARGET_ALTIVEC"
"vspltisb %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltish"
[(set (match_operand:V8HI 0 "register_operand" "=v")
! (unspec:V8HI [(match_operand:QI 1 "immediate_operand" "i")]
! UNSPEC_VSPLTISH))]
"TARGET_ALTIVEC"
"vspltish %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisw"
[(set (match_operand:V4SI 0 "register_operand" "=v")
! (unspec:V4SI [(match_operand:QI 1 "immediate_operand" "i")]
! UNSPEC_VSPLTISW))]
"TARGET_ALTIVEC"
"vspltisw %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisw_v4sf"
[(set (match_operand:V4SF 0 "register_operand" "=v")
! (unspec:V4SF [(match_operand:QI 1 "immediate_operand" "i")] 142))]
"TARGET_ALTIVEC"
"vspltisw %0,%1"
[(set_attr "type" "vecperm")])
--- 1491,1557 ----
"TARGET_ALTIVEC"
"vxor %0,%1,%2"
[(set_attr "type" "vecsimple")])
+ ;; End of vector xor's
(define_insn "altivec_vspltb"
[(set (match_operand:V16QI 0 "register_operand" "=v")
! (vec_duplicate:V16QI
! (vec_select:QI (match_operand:V16QI 1 "register_operand" "v")
! (parallel
! [(match_operand:QI 2 "immediate_operand" "i")]))))]
"TARGET_ALTIVEC"
"vspltb %0,%1,%2"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vsplth"
[(set (match_operand:V8HI 0 "register_operand" "=v")
! (vec_duplicate:V8HI
! (vec_select:HI (match_operand:V8HI 1 "register_operand" "v")
! (parallel
! [(match_operand:QI 2 "immediate_operand" "i")]))))]
"TARGET_ALTIVEC"
"vsplth %0,%1,%2"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltw"
[(set (match_operand:V4SI 0 "register_operand" "=v")
! (vec_duplicate:V4SI
! (vec_select:SI (match_operand:V4SI 1 "register_operand" "v")
! (parallel
! [(match_operand:QI 2 "immediate_operand" "i")]))))]
"TARGET_ALTIVEC"
"vspltw %0,%1,%2"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisb"
[(set (match_operand:V16QI 0 "register_operand" "=v")
! (vec_duplicate:V16QI
! (match_operand:QI 1 "immediate_operand" "i")))]
"TARGET_ALTIVEC"
"vspltisb %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltish"
[(set (match_operand:V8HI 0 "register_operand" "=v")
! (vec_duplicate:V8HI
! (sign_extend:HI (match_operand:QI 1 "immediate_operand" "i"))))]
"TARGET_ALTIVEC"
"vspltish %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisw"
[(set (match_operand:V4SI 0 "register_operand" "=v")
! (vec_duplicate:V4SI
! (sign_extend:SI (match_operand:QI 1 "immediate_operand" "i"))))]
"TARGET_ALTIVEC"
"vspltisw %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisw_v4sf"
[(set (match_operand:V4SF 0 "register_operand" "=v")
! (vec_duplicate:V4SF
! (float:SF (sign_extend:SI
! (match_operand:QI 1 "immediate_operand" "i")))))]
"TARGET_ALTIVEC"
"vspltisw %0,%1"
[(set_attr "type" "vecperm")])
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RFC: PR14880 vec_duplicate or vec_select?
2004-11-15 20:04 ` Dorit Naishlos
@ 2004-11-15 17:28 ` David Edelsohn
2004-11-15 20:50 ` Aldy Hernandez
0 siblings, 1 reply; 15+ messages in thread
From: David Edelsohn @ 2004-11-15 17:28 UTC (permalink / raw)
To: Dorit Naishlos; +Cc: Aldy Hernandez, gcc
>>>>> Dorit Naishlos writes:
Dorit> By the way, for initialization of a vector register with an invariant (e.g.
Dorit> testcase vect-25.c), we still get the following code (the invariant is in
Dorit> r3):
Dorit> I'm not sure if this was part of David's concern when he opened this PR, or
Dorit> should this be a separate PR.
It is a related concern.
vec_init needs to be defined for Altivec.
David
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RFC: PR14880 vec_duplicate or vec_select?
2004-11-15 13:12 ` Aldy Hernandez
@ 2004-11-15 20:04 ` Dorit Naishlos
2004-11-15 17:28 ` David Edelsohn
0 siblings, 1 reply; 15+ messages in thread
From: Dorit Naishlos @ 2004-11-15 20:04 UTC (permalink / raw)
To: Aldy Hernandez; +Cc: David Edelsohn, gcc
> Try this.
This one works (i.e - bootstrapped and passed the vectorization testcases
on ppc-darwin).
By the way, for initialization of a vector register with an invariant (e.g.
testcase vect-25.c), we still get the following code (the invariant is in
r3):
mr r9,r3
mr r10,r3
mr r11,r3
mr r12,r3
L6:
addi r7,r1,1104
stw r9,0(r7)
stw r10,4(r7)
stw r11,8(r7)
stw r12,12(r7)
lvx v0,0,r7
stvx v0,0,r2
addi r2,r2,16
bdnz L6
instead of, say:
stw r3,0(r2)
lvewx v0,0,r2
vspltw v0,v0,0
L4:
stvx v0,r2,r0
addi r2,r2,16
bdnz L4
I'm not sure if this was part of David's concern when he opened this PR, or
should this be a separate PR.
dorit
Aldy Hernandez
<aldyh@redhat.com To: Dorit Naishlos/Haifa/IBM@IBMIL
> cc: David Edelsohn <dje@watson.ibm.com>, gcc@gcc.gnu.org
Subject: Re: RFC: PR14880 vec_duplicate or vec_select?
15/11/2004 14:39
> It bootstrapped for me on powerpc-darwin, but I get an ICE if I try to
> compile with -maltivec:
Whoops. Typo. Arghhh... I need to get my AltiVec box back.
Try this.
Thanks.
Aldy
* config/rs6000/altivec.md ("altivec_vsplth"): Rewrite with
vec_duplicate.
(altivec_vspltb): Same.
(altivec_vspltw): Same.
(altivec_vspltisb): Same.
(altivec_vspltish): Same.
(altivec_vspltisw): Same.
(altivec_vspltisw_v4sf): Same.
(define_constants): Remove UNSPEC_VSPLTISB, UNSPEC_VSPLTISW,
UNSPEC_VSPLTISH.
Move "End of vector xor's" comment to the right place.
Index: config/rs6000/altivec.md
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/altivec.md,v
retrieving revision 1.24
diff -c -p -r1.24 altivec.md
*** config/rs6000/altivec.md 7 Oct 2004 16:05:34 -0000
1.24
--- config/rs6000/altivec.md 15 Nov 2004 12:37:14 -0000
***************
*** 20,29 ****
;; MA 02111-1307, USA.
(define_constants
! [(UNSPEC_VSPLTISW 141)
! (UNSPEC_VSPLTISH 140)
! (UNSPEC_VSPLTISB 139)
! (UNSPEC_VCMPBFP 50)
(UNSPEC_VCMPEQUB 51)
(UNSPEC_VCMPEQUH 52)
(UNSPEC_VCMPEQUW 53)
--- 20,26 ----
;; MA 02111-1307, USA.
(define_constants
! [(UNSPEC_VCMPBFP 50)
(UNSPEC_VCMPEQUB 51)
(UNSPEC_VCMPEQUH 52)
(UNSPEC_VCMPEQUW 53)
***************
*** 1494,1552 ****
"TARGET_ALTIVEC"
"vxor %0,%1,%2"
[(set_attr "type" "vecsimple")])
(define_insn "altivec_vspltb"
[(set (match_operand:V16QI 0 "register_operand" "=v")
! (unspec:V16QI [(match_operand:V16QI 1 "register_operand" "v")
! (match_operand:QI 2 "immediate_operand" "i")]
136))]
"TARGET_ALTIVEC"
"vspltb %0,%1,%2"
[(set_attr "type" "vecperm")])
- ;; End of vector xor's
(define_insn "altivec_vsplth"
[(set (match_operand:V8HI 0 "register_operand" "=v")
! (unspec:V8HI [(match_operand:V8HI 1 "register_operand" "v")
! (match_operand:QI 2 "immediate_operand" "i")]
137))]
"TARGET_ALTIVEC"
"vsplth %0,%1,%2"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltw"
[(set (match_operand:V4SI 0 "register_operand" "=v")
! (unspec:V4SI [(match_operand:V4SI 1 "register_operand" "v")
! (match_operand:QI 2 "immediate_operand" "i")]
138))]
"TARGET_ALTIVEC"
"vspltw %0,%1,%2"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisb"
[(set (match_operand:V16QI 0 "register_operand" "=v")
! (unspec:V16QI [(match_operand:QI 1 "immediate_operand" "i")]
! UNSPEC_VSPLTISB))]
"TARGET_ALTIVEC"
"vspltisb %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltish"
[(set (match_operand:V8HI 0 "register_operand" "=v")
! (unspec:V8HI [(match_operand:QI 1 "immediate_operand" "i")]
! UNSPEC_VSPLTISH))]
"TARGET_ALTIVEC"
"vspltish %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisw"
[(set (match_operand:V4SI 0 "register_operand" "=v")
! (unspec:V4SI [(match_operand:QI 1 "immediate_operand" "i")]
! UNSPEC_VSPLTISW))]
"TARGET_ALTIVEC"
"vspltisw %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisw_v4sf"
[(set (match_operand:V4SF 0 "register_operand" "=v")
! (unspec:V4SF [(match_operand:QI 1 "immediate_operand" "i")]
142))]
"TARGET_ALTIVEC"
"vspltisw %0,%1"
[(set_attr "type" "vecperm")])
--- 1491,1557 ----
"TARGET_ALTIVEC"
"vxor %0,%1,%2"
[(set_attr "type" "vecsimple")])
+ ;; End of vector xor's
(define_insn "altivec_vspltb"
[(set (match_operand:V16QI 0 "register_operand" "=v")
! (vec_duplicate:V16QI
! (vec_select:QI (match_operand:V16QI 1 "register_operand" "v")
! (parallel
! [(match_operand:QI 2
"immediate_operand" "i")]))))]
"TARGET_ALTIVEC"
"vspltb %0,%1,%2"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vsplth"
[(set (match_operand:V8HI 0 "register_operand" "=v")
! (vec_duplicate:V8HI
! (vec_select:HI (match_operand:V8HI 1 "register_operand" "v")
! (parallel
! [(match_operand:QI 2
"immediate_operand" "i")]))))]
"TARGET_ALTIVEC"
"vsplth %0,%1,%2"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltw"
[(set (match_operand:V4SI 0 "register_operand" "=v")
! (vec_duplicate:V4SI
! (vec_select:SI (match_operand:V4SI 1 "register_operand" "v")
! (parallel
! [(match_operand:QI 2
"immediate_operand" "i")]))))]
"TARGET_ALTIVEC"
"vspltw %0,%1,%2"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisb"
[(set (match_operand:V16QI 0 "register_operand" "=v")
! (vec_duplicate:V16QI
! (match_operand:QI 1 "immediate_operand" "i")))]
"TARGET_ALTIVEC"
"vspltisb %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltish"
[(set (match_operand:V8HI 0 "register_operand" "=v")
! (vec_duplicate:V8HI
! (sign_extend:HI (match_operand:QI 1 "immediate_operand"
"i"))))]
"TARGET_ALTIVEC"
"vspltish %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisw"
[(set (match_operand:V4SI 0 "register_operand" "=v")
! (vec_duplicate:V4SI
! (sign_extend:SI (match_operand:QI 1 "immediate_operand"
"i"))))]
"TARGET_ALTIVEC"
"vspltisw %0,%1"
[(set_attr "type" "vecperm")])
(define_insn "altivec_vspltisw_v4sf"
[(set (match_operand:V4SF 0 "register_operand" "=v")
! (vec_duplicate:V4SF
! (float:SF (sign_extend:SI
! (match_operand:QI 1 "immediate_operand"
"i")))))]
"TARGET_ALTIVEC"
"vspltisw %0,%1"
[(set_attr "type" "vecperm")])
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RFC: PR14880 vec_duplicate or vec_select?
2004-11-15 17:28 ` David Edelsohn
@ 2004-11-15 20:50 ` Aldy Hernandez
0 siblings, 0 replies; 15+ messages in thread
From: Aldy Hernandez @ 2004-11-15 20:50 UTC (permalink / raw)
To: David Edelsohn; +Cc: Dorit Naishlos, gcc
Dorit, I'm going to commit the patch you tested to mainline.
> It is a related concern.
>
> vec_init needs to be defined for Altivec.
David, could you please add a a PR for vec_init and assign it to me?
I'll see if I can take a stab at it.
Aldy
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2004-11-15 20:12 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-11-06 0:11 RFC: PR14880 vec_duplicate or vec_select? Aldy Hernandez
2004-11-06 2:12 ` David Edelsohn
2004-11-06 8:42 ` David Edelsohn
2004-11-06 16:58 ` Aldy Hernandez
2004-11-07 13:15 ` Dorit Naishlos
2004-11-07 14:28 ` Aldy Hernandez
2004-11-11 21:05 ` Aldy Hernandez
2004-11-14 10:41 ` Dorit Naishlos
2004-11-14 12:09 ` Aldy Hernandez
2004-11-14 15:03 ` Aldy Hernandez
2004-11-15 12:39 ` Dorit Naishlos
2004-11-15 13:12 ` Aldy Hernandez
2004-11-15 20:04 ` Dorit Naishlos
2004-11-15 17:28 ` David Edelsohn
2004-11-15 20:50 ` Aldy Hernandez
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).