--- Additional Comments From guardia at sympatico dot ca 2005-06-22 22:59
---
Thanks to Uros and everybody!
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22
22:17 ---
Fixed.
--
What|Removed |Added
Status|WAITING |RESOLVED
--- Additional Comments From guardia at sympatico dot ca 2005-06-22 21:59
---
Yup, excited, today, I just compiled the mainbranch to check this out
(gcc-4.1-20050618) and it seems to be fixed! I don't see any strange movlps in
any of the code I tried to compile with it. Can be moved to F
--- Additional Comments From uros at kss-loka dot si 2005-06-22 07:02
---
As this bug is getting a bit confused, I have summarised testcases below:
--cut here--
#include
__m64 moo_1 (int i)
{
__m64 tmp = _mm_cvtsi32_si64 (i);
return tmp;
}
__m64 moo_2 (__m64 mmx1)
{
__m64 mmx2 =
--- Additional Comments From guardia at sympatico dot ca 2005-06-21 13:26
---
Hum, it will be interesting to test this (it will have to wait a couple of
weeks), but the problem with this here is that there is no "mov" instructions
that can move stuff between MMX registers and SSE registe
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-21
11:18 ---
Is the emms issue mentioned in comment #14 fixed with Uros' patch proposed
here: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01724.html?
--
What|Removed |Added
--- Additional Comments From guardia at sympatico dot ca 2005-01-29 19:21
---
Hum, ok we can do a "movd %mm0, %eax", that's why it gets combined...
Well, I give up. The V8QI (and whatever) -> V2SI conversion seems to be causing
all the trouble here if we look at the RTL of something li
--- Additional Comments From guardia at sympatico dot ca 2005-01-29 04:47
---
Hum, there apparently seems to be a problem with the optimization stages.. I
cooked up another snippet :
void moo(__m64 i, unsigned int *r)
{
unsigned int tmp = __builtin_ia32_vec_ext_v2si (i, 0);
*r = t
--- Additional Comments From guardia at sympatico dot ca 2005-01-27 22:55
---
I think I'm starting to see the problem here... I tried to understand more of
the code, and from this and what you tell me, gcc find registers to use and then
finds instructions to that fits the bill. So preven
--- Additional Comments From guardia at sympatico dot ca 2005-01-27 06:19
---
Ok, so from what I gather, the backend is being designed for the autovectorizer
which will probably only work right with SSE2 (on x86 that is), as mucking with
emms will probably bring too much trouble. Second,
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-27 03:55
---
PS, your best solution, for now, is simply to use -mno-sse for the files
in which you have mmx code. Move the sse code to a separate file. That
really is all I can do or suggest.
--
http://gcc.gnu.org/bugz
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-27 03:52
---
> So, is there some sort of "pragma" that could be used to disable SSE
> registers(force -mmmx sort of) for only part of some code?
No.
> __m64 should always be on mmx registers, and __m128 should always be o
--- Additional Comments From guardia at sympatico dot ca 2005-01-27 02:30
---
Ok ok, SSE is not enabled by default on Athlon...
So, is there some sort of "pragma" that could be used to disable SSE registers
(force -mmmx sort of) for only part of some code?
The way I see it, the probl
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-27 00:11
---
(In reply to comment #10)
> That seems like some weird bug here. There musn't be a THAT big of a
> difference
> between the code for pentium3 and the one for athlon right?
Well, duh, athlon doesn't have sse.
--- Additional Comments From guardia at sympatico dot ca 2005-01-27 00:08
---
Oh oh, I think I'm getting somewhere... if I use both -march=athlon and -msse
flags I get the "bad" code. Let me summarize this :
-march=pentium3 = bad
-msse = bad
-march=athlon = good (ie.: no weird movss
--- Additional Comments From guardia at sympatico dot ca 2005-01-26 23:59
---
Even stranger, it doesn't do it with -march=athlon either... only
-march=pentium, pentium2 or pentium3... ?
That seems like some weird bug here. There musn't be a THAT big of a difference
between the code for
--- Additional Comments From guardia at sympatico dot ca 2005-01-26 23:51
---
I'm wondering, would there be a #pragma directive that would we could use to
surround the MMX instrinsics function, and that would prevent the compiler from
using the XMM registers??
--
http://gcc.gnu.org/b
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-26 18:40
---
Sorry, but this appears to be unfixable without a complete rewrite of MMX
support.
Everything I tried had side effects where MMX instructions were used when we
were
not using MMX intrinsics.
--
Wh
--
What|Removed |Added
AssignedTo|rth at gcc dot gnu dot org |unassigned at gcc dot gnu
||dot org
Status|ASSIGNED
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-26 15:47
---
Hmm. Seems to only happen with -march=pentium3, and not -march=pentium4...
--
What|Removed |Added
---
--- Additional Comments From guardia at sympatico dot ca 2005-01-24 18:09
---
MMX intrinsics don't seem to be a standard (?), but I'm under the impression
that _mm_cvtsi32_si64 is supposed to generate MMX code. I just tested With (GCC)
4.0.0 20050123, and with -mmmx flag, the result is s
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-20 18:44
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-20
18:34 ---
Subject: Bug 19530
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-20 18:34:13
Modified files:
gcc: ChangeLog
gcc/config/i386: i
--
What|Removed |Added
Summary|MMX load intrinsic produces |MMX load intrinsic produces
|SSE superflus instructions |SSE superfluous instructions
26 matches
Mail list logo
