lkml.org 
[lkml]   [2004]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: raid 5 with >= 5 members broken on x86
From
Date
On Feb 26, 2004, Linus Torvalds <torvalds@osdl.org> wrote:

>> > There is nothing to say that gcc wouldn't do a re-load or something
>> > in between, so you really need to tell the _first_ ask about it.

>> The only other reload it could do is an input reload of p4 and p5,
>> which, again, doesn't matter, because p4 and p5 are dead anyway.

> Ok. That's the missing piece. The thing is wrong, but we don't care,
> because even if gcc saves the old values for some silly reload, they're
> dead and uninteresting.

Yup.

> Ok. I did the silly one-liner

That's good enough for me. I tested that before trying this better
approach, and it worked.

> but if the "don't care" approach really improves code generation,
> feel free to send one that fixes both the P5 and PII cases..

It's not the code generation that is improved, it's just that we can
then refrain from pushing and popping something that nobody cares
about. It would have worked to just assign a random value to p4 and
p5 after the asm loop; it would be dead anyway. As long as we made
sure p4 and p5 weren't shared with anything else before, that is.

--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year! oliva@{lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist Professional serial bug killer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:01    [W:0.063 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site