12 Feb
2004
12 Feb
'04
8:38 a.m.
can anybody help out with gcc inline assembly syntax applied to sse
registers/memory locations?
for a simplified example, i'm using
float t[4];
...
asm ("movaps %%xmm1, %0" : : "m" (t[0]));
to move 4 packed floats from xmm1 into 't'.
my suspicion is that gcc concludes from the expression that only t[0]
has changed, so if i'm unlucky the optimizer ignores the contents of
t[1:]. it does the right thing right now, but i want to go sure this
is reliable under all conditions.
one possible solution seems to use struct/union instead of float[4]
(iirc that's the way fftw-3 does it) but i'm aesthetically inclined
towards the more direct float[] notation.
i've dug deep into the gcc info files, but they rarely touch the
issue (and are darn tedious to read). using gcc-3.x builtins is not an
option.
so, can anybody help me code this properly?
thanks,
tim
12 Feb
12 Feb
4:59 p.m.
Tim Goetze wrote:
can anybody help out with gcc inline assembly syntax
applied to sse
registers/memory locations?
for a simplified example, i'm using
float t[4];
...
asm ("movaps %%xmm1, %0" : : "m" (t[0]));
to move 4 packed floats from xmm1 into 't'.
I couldn't get this to fail in practice - though I didn't
try all that hard - unless t isn't on a 16 byte boundary
in which case it segfaults.
In theory however your code is telling the compiler that
array element t[0] is in memory from which the instruction
reads. It should be more like:
asm ("movaps %%xmm1 %0" : "=m" (t) );
which now tells the compiler that the entire array t
is in memory to which the instruction writes. This
*ought* to discourage the optimiser from doing
anything too drastic. (Maybe/AFAIK/IANAL/etc).
Simon Jenkins
(Bristol, UK)
5:44 p.m.
Simon Jenkins wrote:
it failed here just a minute ago, with g++ -O6. not a segfault, but
gcc seemed to think that some members of t are zero and omitted them
from the final summation in my code (r = t[0] + t[1] + t[2] + t[3]).
for a
simplified example, i'm using
float t[4];
...
asm ("movaps %%xmm1, %0" : : "m" (t[0]));
to move 4 packed floats from xmm1 into 't'.
I couldn't get this to fail in practice - though I didn't
try all that hard - unless t isn't on a 16 byte boundary
in which case it segfaults. In theory however your code is telling the compiler
that
array element t[0] is in memory from which the instruction
reads. It should be more like:
asm ("movaps %%xmm1 %0" : "=m" (t) );
which now tells the compiler that the entire array t
is in memory to which the instruction writes. This
*ought* to discourage the optimiser from doing
anything too drastic. (Maybe/AFAIK/IANAL/etc).
you're right of course, 't' should be an input, not an output.
however,
asm ("movaps %%xmm1 %0" : "=m" (t));
segfaults, but
asm ("movaps %%xmm1 %0" : "=m" (t[0]));
works. think i'll have to resort to 128 bit wide data types, a
simple cast should do. all this gcc inline asm stuff is ugly anyway,
and what's another cast among friends.
thanks,
tim
7:50 p.m.
Tim Goetze wrote:
Simon Jenkins wrote:
it failed here just a minute ago, with g++ -O6. not a segfault, but
gcc seemed to think that some members of t are zero and omitted them
from the final summation in my code (r = t[0] + t[1] + t[2] + t[3]).
I can definitely get
asm ("movaps %%xmm1 %0" : "=m" (t[0]));
to exhibit the optimisation problem (the one I couldn't get your
original line to show) and then fix it again by removing the [0].
I was getting a segfault on about 50% of compiles, as I modified
the code, because the array was being aligned to 8 byte boundaries
but not to 16 bytes. Declaring it as
float t[4] __attribute__ ((aligned(16)));
got rid of those. Note though that this attribute doesn't work for
automatic variables.
Simon Jenkins
(Bristol, UK)
for a
simplified example, i'm using
float t[4];
...
asm ("movaps %%xmm1, %0" : : "m" (t[0]));
to move 4 packed floats from xmm1 into 't'.
I couldn't get this to fail in practice - though I didn't
try all that hard - unless t isn't on a 16 byte boundary
in which case it segfaults.
In theory however your code is telling the
compiler that
array element t[0] is in memory from which the instruction
reads. It should be more like:
asm ("movaps %%xmm1 %0" : "=m" (t) );
which now tells the compiler that the entire array t
is in memory to which the instruction writes. This
*ought* to discourage the optimiser from doing
anything too drastic. (Maybe/AFAIK/IANAL/etc).
you're right of course, 't' should be an input, not an output.
however,
asm ("movaps %%xmm1 %0" : "=m" (t));
segfaults, but
asm ("movaps %%xmm1 %0" : "=m" (t[0]));
works. think i'll have to resort to 128 bit wide data types, a
simple cast should do. all this gcc inline asm stuff is ugly anyway,
and what's another cast among friends.
8:48 p.m.
Simon Jenkins wrote:
I can definitely get
asm ("movaps %%xmm1 %0" : "=m" (t[0]));
to exhibit the optimisation problem (the one I couldn't get your
original line to show) and then fix it again by removing the [0].
I was getting a segfault on about 50% of compiles, as I modified
the code, because the array was being aligned to 8 byte boundaries
but not to 16 bytes. Declaring it as
float t[4] __attribute__ ((aligned(16)));
got rid of those. Note though that this attribute doesn't work for
automatic variables.
ok, here is a distilled test of how i allocate and use the
instructions:
int main (int argc, char ** argv)
{
char scratch [128 + 15];
float f = 2.3;
int s = (int) scratch;
s &= 0xF;
if (s)
s = 16 - s;
float * d = (float *) (((char *) scratch) + s);
fprintf (stderr, "%p\n", d);
asm ("movss %0, %%xmm0" : : "m" (f));
asm ("shufps $0, %xmm0, %xmm0");
asm ("movaps %%xmm0, %0" : "=m" (d[0]));
printf ("%.2f %.2f %.2f %.2f\n", d[0], d[1], d[2], d[3]);
}
you'll agree that the program should print "2.30 2.30 2.30 2.30".
it does if you use "=m" (d[0]). if you say "=m" (d), it doesn't.
here's what the assembly block compiles to with "=m" (d):
#APP
movss -148(%ebp), %xmm0
shufps $0, %xmm0, %xmm0
movaps %xmm0, -156(%ebp)
#NO_APP
and here's with "=m" (d[0]):
#APP
movss -148(%ebp), %xmm0
shufps $0, %xmm0, %xmm0
#NO_APP
movl -156(%ebp),%eax
#APP
movaps %xmm0, (%eax)
#NO_APP
so saying "=m" (d) causes xmm0 to be written to &d, not d, as
intended. if &d isn't 128-bit aligned, it will segfault now.
even if it is, that's not where we wanted the numbers from xmm0
to go ...
tim
13 Feb
13 Feb
4:11 p.m.
Tim Goetze wrote:
Simon Jenkins wrote:
The discrepency here is because you originally said you were trying to
get the data into a named array of floats:
float t[4];
but it turns out you're actually trying to get them into some memory
to which you have a named pointer:
float *d;
Now, there are a great many circumstances in which you could treat
such names interchangeably, but this isn't one of them.
The following code demonstrates
asm ("movaps %%xmm0, %0" : "=m" (d));
working correctly if d is an aligned array of floats. Also, if
you change the d to d[0], it exhibits the optimization problem.
/* start */
float d[4] __attribute__ ((aligned(16))) = { 1.1f, 1.1f, 1.1f, 1.1f };
int main (int argc, char ** argv)
{
float z = 1.1f;
float f = 2.3f;
z += 3.3f;
asm ("movss %0, %%xmm0" : : "m" (f));
asm ("shufps $0, %xmm0, %xmm0");
asm ("movaps %%xmm0, %0" : "=m" (d));
z += d[1];
printf ("%.2f %.2f %.2f %.2f\n", d[0], d[1], d[2], d[3]);
printf ("z is %.2f\n", z );
}
/* end */
We're expecting (and we get):
2.30 2.30 2.30 2.30
z is 6.70
but using d[0] instead of d we end up getting:
2.30 2.30 2.30 2.30
z is 5.50
Simon Jenkins
(Bristol, UK)
I can definitely get
asm ("movaps %%xmm1 %0" : "=m" (t[0]));
to exhibit the optimisation problem (the one I couldn't get your
original line to show) and then fix it again by removing the [0].
[snip]
ok, here is a distilled test of how i allocate and use the
instructions:
int main (int argc, char ** argv)
{
char scratch [128 + 15];
float f = 2.3;
int s = (int) scratch;
s &= 0xF;
if (s)
s = 16 - s;
float * d = (float *) (((char *) scratch) + s);
fprintf (stderr, "%p\n", d);
asm ("movss %0, %%xmm0" : : "m" (f));
asm ("shufps $0, %xmm0, %xmm0");
asm ("movaps %%xmm0, %0" : "=m" (d[0]));
printf ("%.2f %.2f %.2f %.2f\n", d[0], d[1], d[2], d[3]);
}
you'll agree that the program should print "2.30 2.30 2.30 2.30".
it does if you use "=m" (d[0]). if you say "=m" (d), it doesn't.
here's what the assembly block compiles to with "=m" (d):
#APP
movss -148(%ebp), %xmm0
shufps $0, %xmm0, %xmm0
movaps %xmm0, -156(%ebp)
#NO_APP
and here's with "=m" (d[0]):
#APP
movss -148(%ebp), %xmm0
shufps $0, %xmm0, %xmm0
#NO_APP
movl -156(%ebp),%eax
#APP
movaps %xmm0, (%eax)
#NO_APP
so saying "=m" (d) causes xmm0 to be written to &d, not d, as
intended. if &d isn't 128-bit aligned, it will segfault now.
even if it is, that's not where we wanted the numbers from xmm0
to go ...
5:04 p.m.
[Simon Jenkins]
indeed it isn't, you're right. in fact, if i'm not mistaken it's the
first time ever i see this distinction make a difference.
i'm not at all convinced that gcc is doing the right thing here;
acting on the difference seems nonsensical to me.
so saying
"=m" (d) causes xmm0 to be written to &d, not d, as
intended. if &d isn't 128-bit aligned, it will segfault now.
even if it is, that's not where we wanted the numbers from xmm0
to go ...
The discrepency here is because you originally said you were trying to
get the data into a named array of floats:
float t[4];
but it turns out you're actually trying to get them into some memory
to which you have a named pointer:
float *d;
Now, there are a great many circumstances in which you could treat
such names interchangeably, but this isn't one of them. The following code demonstrates
[...]
point taken. thanks!
when i look into the code in question the next time (it works well now
so not much incentive), i'll probably do a complete assembler rewrite.
no more messing with my pointers, mr. gcc, thanks.
tim
14 Feb
14 Feb
8:07 a.m.
when i look into the code in question the next time (it
works well now
so not much incentive), i'll probably do a complete assembler rewrite.
no more messing with my pointers, mr. gcc, thanks.
fwiw,
float * t = &four_floats_somewhere_on_a_128_bit_boundary;
asm ("
movl %0, %%eax
movaps %%xmm4, (%%eax)
flds (%%eax)
fadds 4(%%eax)
fadds 8(%%eax)
fadds 12(%%eax)
fstps (%%eax)" : : "p" (t) : "%eax",
"%st");
sums xmm4 into t[0].
tim
7387
days inactive
7389
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
2 participants
participants (2)
-
Simon Jenkins -
Tim Goetze