M. Warner Losh schrieb:
In message: <49fa8d73.6040...@gmx.de>
Christoph Mallon <christoph.mal...@gmx.de> writes:
: M. Warner Losh schrieb:
: > In message: <20090428114754.gb89...@server.vk2pj.dyndns.org>
: > Peter Jeremy <peterjer...@optushome.com.au> writes:
: > : >> +.Sh LOCAL VARIABLES
: > :
: > : >Last, but definitely not least, I added this paragraph about the use of
: > : >local variables. This is to clarify, how today's compilers handle
: > : >unaliased local variables.
: > :
: > : Every version of gcc that FreeBSD has ever used would do this for
: > : primitive types when optimisation was enabled. This approach can
: > : become expensive in stack (and this is an issue for kernel code) when
: > : using non-primitive types or when optimisation is not enabled (though
: > : I'm not sure if this is supported). Assuming that gcc (and icc and
: > : clang) behaves as stated in all supported optimisation modes, this
: > : change would appear to be quite safe to make.
: >
: > Agreed, in general. We don't want to optimize our code style based on
: > what one compiler does, perhaps on x86.
:
: I'm not sure whether I understand this - in particular the last three words.
I'm saying we shouldn't tune our coding standard to the optimizations
that the compiler of the hour gives, especially if those optimizations
to the style are tuned to one architecture. Since there's little
evidence presented on how these style changes will help any
architecture, it is hard to judge if this is the case or not.
The main goal of the proposed change is not about optimisation, but
about clarity of the code: It is better to declare multiple variables
with meaningful names instead of having one generic "int k;" used in
several different contexts. I just also mentioned, that re-using
variables in different contexts when taking its address is involved,
leads to worse machine code, but this is a minor point. It's just that
clarity for a reader and quality of the generated code nicely correlate
here.
Christoph
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
