http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
Jackie Rosen jackie.rosen at hushmail dot com changed:
What|Removed |Added
CC|
--- Comment #40 from astrange at ithinksw dot com 2009-10-18 19:56 ---
Linked from http://x264dev.multimedia.cx/?p=185, I'd forgotten all about the
ridiculous flamewar in this one.
Just as a note, the actual definitions of the four variables (from liba52):
x2k = x + 2 * k;
x3k =
--- Comment #38 from xyzzy at speakeasy dot org 2007-02-27 19:36 ---
(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 desireable to have a asm
constraint like m without this restriction
--- 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 desireable to have a asm
constraint like
--- Comment #36 from xyzzy at speakeasy dot org 2006-11-08 20:03 ---
(In reply to comment #21)
asm volatile(
: =m (*(unsigned int*)(src + 0*stride)),
=m (*(unsigned int*)(src + 1*stride)),
=m (*(unsigned int*)(src + 2*stride)),
=m
--- 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*)(src + 1*stride)),
=m (*(unsigned int*)(src +
--- Comment #34 from langer_mann at web dot de 2006-04-21 15:56 ---
The reason is dead simple: register allocation is NP-complete, so it
is even *theoretically* not possible to write register allocators that
always find a coloring.
Not at all. If a problem is NP-hard, you can in
--- Comment #35 from langer_mann at web dot de 2006-04-21 15:59 ---
(In reply to comment #34)
The reason is dead simple: register allocation is NP-complete, so it
is even *theoretically* not possible to write register allocators that
always find a coloring.
Not at all. If a
--- Comment #33 from pinskia at gcc dot gnu dot org 2006-01-19 12:38
---
*** Bug 25853 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #31 from pinskia at gcc dot gnu dot org 2005-12-02 17:44
---
*** Bug 25226 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #32 from pinskia at gcc dot gnu dot org 2005-12-02 17:46
---
*** Bug 25221 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-05
22:20 ---
*** Bug 23743 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-26
00:29 ---
*** Bug 20645 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From spigel at olvs dot miee dot ru 2005-01-24
06:45 ---
Subject: Re: source doesn't compile with -O0 but they
compile with -O3
Yeah, fine battle!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-22
12:14 ---
Martin, you should realize that this problem *cannot* be solved. Yes,
there will perhaps be a time when this particular test case compiles,
though I think that is unlikely. But anyway, then there will be
--- Additional Comments From stian at nixia dot no 2005-01-22 15:58 ---
if you resolve all memory-referenses to temporary variables
void *a=(src + 0*stride)
and use those instead. Doesn't that lessen the stress the register-allocator is
given?
--
--- 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 confuse the register allocator.
The reason is dead simple: register allocation is NP-complete, so it
is even *theoretically* not possible to write register allocators that
always find a coloring.
register allocation in general is NP-complete, yes, but it seems u forget
that
this is about finding the optimal solution while gcc
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-01-22
17:21 ---
Subject: Re: source doesn't compile with -O0 but they
compile with -O3
The reason is dead simple: register allocation is NP-complete, so it
is even *theoretically* not possible to write register
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz
2005-01-21 12:39 ---
(In reply to comment #15)
I will note for the record that disabling local-alloc will resolve
this problem. A patch for that is in the audit trail of another bug,
for unrelated reasons:
--- Additional Comments From falk at debian dot org 2005-01-21 13:55
---
(In reply to comment #17)
And IMHO this shoul be perfectly
valid, since the operands to the asm construction are all marked as m (!!!),
so no registers should be needed for that!
Huh? The memory operands are
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz
2005-01-21 14:10 ---
(In reply to comment #18)
Huh? The memory operands are not at a compile time constant address, so of
course
you need a register to hold them. Of course, you need only one register for
all of
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
15:15 ---
*** Bug 19549 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz
2005-01-21 15:49 ---
OK, sorry, the Bug 19549 testcode passes with -O1 and above, but the original,
that it was stripped from (maybe too much stripped) doesn't:
-- test2.c -
extern
--- Additional Comments From falk at debian dot org 2005-01-21 16:33
---
(In reply to comment #21)
Or do you consider this also invalid?
It doesn't seem invalid to me. But it is basically impossible to write the
register allocator such that it finds a register allocation for every
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz
2005-01-21 16:48 ---
(In reply to comment #22)
It doesn't seem invalid to me. But it is basically impossible to write the
register allocator such that it finds a register allocation for every
situation
where it's
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-20
21:04 ---
*** Bug 19549 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From stian at nixia dot no 2005-01-01 17:15 ---
Reference to other bug-reports:
http://bugs.gentoo.org/show_bug.cgi?id=71360
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-01
17:22 ---
Why do people write inline-asm like this?
It is crazy to do so. Split up the inline-asm correctly.
Anyone who writes like inline-asm should get what they get.
For mmx inline-asm, you should be using the
--- 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.
fix gcc
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-01
22:50 ---
You've just constrained the compiler too much to do anything. You're right
that gcc should produce fewer loads and stores sometimes, but in this case
I suggest you show that this actually hurts you still
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-01
23:05 ---
I will note for the record that disabling local-alloc will resolve
this problem. A patch for that is in the audit trail of another bug,
for unrelated reasons: http://gcc.gnu.org/PR13776. It also happens
32 matches
Mail list logo
