Re: raid 5 with >= 5 members broken on x86

[Alexandre Oliva <aoliva@redhat.com>]

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