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
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
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
"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
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
../../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
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
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
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
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
# 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
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
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, 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
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, 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
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
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
-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
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
"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
> 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
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
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
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.
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
"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, 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
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
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
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
31 matches
Mail list logo
