--- Comment #11 from michaelni at gmx dot at 2008-03-24 00:08 ---
Subject: Re: Performance degradation when
building code that uses MMX intrinsics with gcc-4.0.0
On Sun, Mar 23, 2008 at 10:46:41AM -, ubizjak at gmail dot com wrote:
>
>
> --- Comment #10 fro
--- Comment #9 from michaelni at gmx dot at 2008-03-23 02:49 ---
Subject: Re: Performance degradation when
building code that uses MMX intrinsics with gcc-4.0.0
On Sat, Mar 22, 2008 at 11:01:55AM -, ubizjak at gmail dot com wrote:
>
>
> --- Comment #8 from u
--- Comment #7 from michaelni at gmx dot at 2008-03-22 02:51 ---
You can also replace the inner loop by:
"2: \n\t"
"pxor %%mm1, %%mm1 \n\t"
"movq (%%eax, %%ecx), %%mm0\n\t"
&q
--- Comment #37 from michaelni at gmx dot at 2008-03-22 02:39 ---
Subject: Re: compiled trivial vector intrinsic code is
inefficient
On Fri, Mar 21, 2008 at 10:34:00AM -, ubizjak at gmail dot com wrote:
>
>
> --- Comment #36 from ubizjak at gmail dot com 2
--- Comment #6 from michaelni at gmx dot at 2008-03-22 02:15 ---
As Uros has "challenged me to beat performance of gcc-4.4 generated code by
hand-crafted assembly using the example of PR 21395" heres my entry, sadly i
only have gcc-4.3 compiled ATM for comparission but 4.3
--- Comment #35 from michaelni at gmx dot at 2008-03-20 17:18 ---
Subject: Re: compiled trivial vector intrinsic code is
inefficient
On Thu, Mar 20, 2008 at 09:49:22AM -, ubizjak at gmail dot com wrote:
>
>
> --- Comment #34 from ubizjak at gmail dot com 2
--- Comment #33 from michaelni at gmx dot at 2008-03-20 01:37 ---
Subject: Re: compiled trivial vector intrinsic code is
inefficient
On Wed, Mar 19, 2008 at 11:39:18PM -, uros at gcc dot gnu dot org wrote:
>
>
> --- Comment #26 from uros at gcc dot gnu dot
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michaelni at gmx dot at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35058
--- Comment #39 from michaelni at gmx dot at 2007-02-27 22:50 ---
(In reply to comment #38)
> (In reply to comment #37)
> > now if there is a unwritten rule that "m" operands and variations of them
> > cannot be copied anywhere, then it would be very
--- Comment #37 from michaelni at gmx dot at 2006-11-08 20:45 ---
(In reply to comment #36)
> (In reply to comment #21)
> > asm volatile(""
> > : "=m" (*(unsigned int*)(src + 0*stride)),
> > "=m" (*(unsigned int
--- Comment #11 from michaelni at gmx dot at 2006-02-11 13:54 ---
(In reply to comment #9)
> Re. comment #8:
> "exponential decaying performance which it has so accurately followed since
> 2.95"
>
> Can you back this up with numbers, or are you just trolling?
--- Comment #8 from michaelni at gmx dot at 2006-02-11 11:40 ---
I really think this should be fixed, otherwise gcc wont be able to follow its
exponential decaying performance which it has so accurately followed since 2.95
at least, to show clearer how much speed we could loose by
Severity: normal
Priority: P2
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michaelni at gmx dot at
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: x86-linux
GCC host triplet: x86-linux
GCC target triplet:
--- Additional Comments From michaelni at gmx dot at 2005-01-22 17:10
---
(In reply to comment #14)
> In any case, just because code is syntactically "valid"
> GNU C doesn't mean gcc can always compile it. With this kind of inline asm,
> you're bound to c
--- Additional Comments From michaelni at gmx dot at 2005-01-01 18:57
---
(In reply to comment #12)
> Why do people write inline-asm like this?
why not? its valid code and a compiler should compile valid code ...
> It is crazy to do so. Split up the inline-asm correctly.
f
15 matches
Mail list logo
