Let's assume that the recent change is what we want, i.e., that the
answer to (1) is "No, these operations should not be part of the vector
extensions because they are not valid scalar extensions." So, that
means we need to answer (2).
We still have the problem that users now can't write machi
Paolo Bonzini wrote:
>
>>> Why did Intel split up these instructions in the first place, is it
>>> because they wanted to have a seperate vector units in some cases?
>>> I don't know and I don't care that much.
>
> To some extent I agree with Andrew Pinski here. Saying that you need
> support i
petruk_gile <[EMAIL PROTECTED]> writes:
> The case is like this:
> In the machine description (*.md) file, sometimes I emit a single RTL
> instruction into multiple ASM instruction. The problem is, in some case I
> need to emit an operand that actually doesn't exist in its RTL
> representation. Fo
On 8/23/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> On 8/23/07, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> >
> > We decided long ago that the extension would be based on what's permitted
> > by C++ valarray rather than by a particular CPU's vector intrinsics. So
> > unless C++ valarray allows
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
| On Thu, 23 Aug 2007, Ian Lance Taylor wrote:
|
| > I think we should revert the patch, and continue permitting the
| > bitwise operations on vector float.
| >
| > There seem to be solid reasons to permit this, and no very strong ones
| > to prohibi
On 8/23/07, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> On Thu, 23 Aug 2007, Ian Lance Taylor wrote:
>
> > I think we should revert the patch, and continue permitting the
> > bitwise operations on vector float.
> >
> > There seem to be solid reasons to permit this, and no very strong ones
> > to p
On Thu, 23 Aug 2007, Ian Lance Taylor wrote:
> I think we should revert the patch, and continue permitting the
> bitwise operations on vector float.
>
> There seem to be solid reasons to permit this, and no very strong ones
> to prohibit it. We can consider it to be a GNU extension for vectors.
Richard Guenther writes:
>As I said - at least for AMD CPUs - it looks like you can freely
>interchange the ps|pd or integer variants of the bitwise and/or
>operations without a penalty.
An example in AMD's "Software Optmization Guide for AMD64 Processors"
suggests that you can't freely interchang
Hi,
On Thu, 23 Aug 2007, Paul Brook wrote:
> > There seem to be solid reasons to permit this, and no very strong ones
> > to prohibit it. We can consider it to be a GNU extension for vectors.
> > Vectors are of course themselves an extension already.
>
> How are you suggesting it be implemented
> There seem to be solid reasons to permit this, and no very strong ones
> to prohibit it. We can consider it to be a GNU extension for vectors.
> Vectors are of course themselves an extension already.
How are you suggesting it be implemented?
Will the front/middle-end convert it to (vNsf)((vNsi
"The types defined in this manner can be used with a subset of
normal C operations. Currently, GCC will allow using the following
operators on these types: +, -, *, /, unary minus, ^, |, &, ~.".
What was missing is "when allowed by the base type". E.g. >> is not
supported.
I think we should
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> > "The types defined in this manner can be used with a subset of
> > normal C operations. Currently, GCC will allow using the following
> > operators on these types: +, -, *, /, unary minus, ^, |, &, ~.".
>
> What was missing is "when allowed by the bas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
H.J. Lu wrote:
> Is there any objection?
No, this is correct and necessary.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGzaGk2ijCOnn/RHQRAlIzAKCQH
IA32 TLS GD access model specifies
leal[EMAIL PROTECTED](,%ebx,1), %eax
call___tls_get_addr
But the current linker also accepts
leal[EMAIL PROTECTED](%ebx), %eax
call___tls_get_addr
However, GD->IE transition needs one more byte to change it to
movl %gs:0, %eax; subl [EMAIL PRO
Brian Sidebotham wrote:
../../gcc/gcc/tree.c: In function "build_string":
../../gcc/gcc/tree.c:1197: internal compiler error: in
iterative_hash_expr, at tree.c:4189
Please submit a full bug report,
with preprocessed source if appropriate.
I have placed the pre-processed file here:
http://www.v
On 8/23/07, Tim Prince <[EMAIL PROTECTED]> wrote:
> The primary icc/icl use of SSE/SSE2 masking operations, of course, is in
> the auto-vectorization of fabs[f] and conditional operations:
>
> sum = 0.f;
> i__2 = *n;
> for (i__ = 1; i__ <= i__2; ++i__)
> if (a[i__] > 0.f
Paolo Bonzini wrote:
I'm curious, does ICC support vector arithmetic like this?
The primary icc/icl use of SSE/SSE2 masking operations, of course, is in
the auto-vectorization of fabs[f] and conditional operations:
sum = 0.f;
i__2 = *n;
for (i__ = 1; i__ <= i__2; ++i__)
On 8/23/07, petruk_gile <[EMAIL PROTECTED]> wrote:
>
> Hi all ..
>
> I'm currently porting GCC into a new processor, and I have a problem in
> instruction scheduling ...
>
> The case is like this:
> In the machine description (*.md) file, sometimes I emit a single RTL
> instruction into multiple AS
1. Introduction
The Summer of Code project "Better Uninitialized Warnings" had
ambitious goals. The option "Wuninitialized" has always been a source
of controversy and frustration. One of the reasons is the conflictive
views as to what should be warned. Initially, we identified two groups
of users
On 8/23/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> I've added 5 minutes ago an XFAILed test for exactly this code. OTOH, I
> have also committed a fix that will avoid producing tons of shuffle and
> unpacking instructions when function "bar" is compiled with "-msse" but
> without "-msse2".
Tha
# cat regressionorbugfix.cc
typedef float v4sf_t __attribute__ ((__vector_size__ (16)));
typedef int v4si_t __attribute__ ((__vector_size__ (16)));
v4sf_t foo(v4sf_t a, v4sf_t b, v4sf_t c) {
return a + (b | c);
}
v4sf_t bar(v4sf_t a, v4sf_t b, v4sf_t c) {
return a + (v4sf_t) ((v4si_t) b
Paolo Bonzini wrote:
Because it's *not* strictly typed. Strict typing means that you accept
the same things accepted for the element type. So it's not a
regression, it's a bug fix.
# cat regressionorbugfix.cc
typedef float v4sf_t __attribute__ ((__vector_size__ (16)));
typedef int v4si_t __at
GCC makes the problem is even worse if only SSE and not SSE 2 instructions
are enabled. Since the integer bitwise instructions are only available
with SSE 2, using casts instead of intrinsics causes GCC to expand the
operation into a long series of instructions.
This was also a bug and a patch
Join Future Movement Official discussion forum
http://www.futuremovement.org/forum
In The Future Movement Forum you can find:
Political section: where you can discuss the latest developments and express
your opinion and thoughts within the political debates and discussions.
Recent news sec
tbp wrote:
Paolo Bonzini wrote:
To some extent I agree with Andrew Pinski here. Saying that you need
support in a generic vector extension for "vector float | vector
float" in order to generate ANDPS and not PXOR, is just wrong. That
should be done by the back-end.
I guess i fail to grasp
../../gcc/gcc/tree.c: In function "build_string":
../../gcc/gcc/tree.c:1197: internal compiler error: in iterative_hash_expr, at
tree.c:4189
Please submit a full bug report,
with preprocessed source if appropriate.
I have placed the pre-processed file here:
http://www.valvers.com/gcc/arm-elf/tr
Paolo Bonzini wrote:
To some extent I agree with Andrew Pinski here. Saying that you need
support in a generic vector extension for "vector float | vector float"
in order to generate ANDPS and not PXOR, is just wrong. That should be
done by the back-end.
I guess i fail to grasp the logic mand
"The types defined in this manner can be used with a subset of normal C
operations. Currently, GCC will allow using the following operators on
these types: +, -, *, /, unary minus, ^, |, &, ~.".
What was missing is "when allowed by the base type". E.g. >> is not
supported.
Paolo
Andrew Pinski wrote:
Which hardware (remember GCC is a generic compiler)? VMX/Altivec and
SPU actually does not have different instructions for bitwise
and/ior/xor for different vector types (it is all the same
instruction). I have ran into ICEs with even bitwise on vector
float/double on x86 a
Ross Ridge wrote:
If I were tbp, I'd just code all his vector operatations using intrinsics.
The other responses in this thread have made it clear that GCC's vector
arithemetic operations are really only designed to be used with the Cell
Broadband Engine and other Power PC processors.
Thing is my
Hi all ..
I'm currently porting GCC into a new processor, and I have a problem in
instruction scheduling ...
The case is like this:
In the machine description (*.md) file, sometimes I emit a single RTL
instruction into multiple ASM instruction. The problem is, in some case I
need to emit an oper
31 matches
Mail list logo
