[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/43541: Unaligned access in pf_normalize_tcpopt()
The following reply was made to PR kern/43541; it has been noted by GNATS.
From: David Holland <dholland-bugs%netbsd.org@localhost>
Subject: Re: kern/43541: Unaligned access in pf_normalize_tcpopt()
Date: Mon, 5 Jul 2010 21:07:27 +0000
On Mon, Jul 05, 2010 at 08:20:03PM +0000, David Laight wrote:
>>> The compiler may well generate code that 'and's the value with 0xff
>>> twice before storing the low 8 bits away!
>> Not very likely, except perhaps with gcc -O0, which is so stupid
>> anyway that there's no point worrying about it.
> Not in my experience!
> I've certainly seen compilers mask with 0xff then save the low bits.
Well, I've also *seen* compilers store temporary values to scratch
slots in the stack and immediately read them back. The question is
whether a reasonably sane and modernish compiler that's been at least
somewhat debugged is going to do anything so silly.
However, it's also moot because such micro-optimizations are not worth
spending time thinking about.
>>> OTOH reversing the two lines may well save a temporary register.
>>> Hmmm... actually you want to cache r->max_rss in a local, the compiler
>>> is most likely required to re-read r->max_rss between the two statements.
>> Why would it be? It's not IIRC marked volatile.
> The aliasing rules ...
Hrm, perhaps, I guess proving that optp and r->max_rss don't
overlap would require global analysis.
David A. Holland
Main Index |
Thread Index |