Re: kern/43541: Unaligned access in pf_normalize_tcpopt()

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR kern/43541; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
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[2] and r->max_rss don't
 overlap would require global analysis.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost