svn commit: trunk/uClibc/libc/unistd
Denys Vlasenko
vda.linux at googlemail.com
Fri Jun 6 22:39:54 PDT 2008
On Friday 06 June 2008 14:50, Bernhard Fischer wrote:
> On Thu, Jun 05, 2008 at 08:24:45PM -0700, vda at uclibc.org wrote:
> >Author: vda
> >Date: 2008-06-05 20:24:45 -0700 (Thu, 05 Jun 2008)
> >New Revision: 22242
> >
> >Log:
> >shrink getopt a bit by using smallints. Run tested (busybox testsuite)
>
> I still think that this route is wrong.
I somewhat agree in a sense that smallints should not be *abused*.
They should be used only in the following cases:
* variables are not on stack but in data or bss, or in rare cases
in a structure which is allocated many times (not typical
for libc code, but happens a lot in bbox)
* variables are bool flags or enum-like values; not much of
arithmetic is done on them (+,-,bitshifts): on many arches
arith ops on narrow ints are bigger and/or slower.
(as opposed to loads/stores and bit tests. If on some arch
even loads/stores and bit tests are bigger, it should use
"smallints" which are just ordinary ints.
I can commit a change which adds a comment with this text
to codebase. Do you want me to do it?
> VRP knows the exact range of values a variable is in. -fnarrow-type
> should deal with this for us, really.
As soon as someone will do flag++ as a bastardized flag = 1
or global_flag = bool_parameter_of_a_function,
this will break.
> fnarrow-types
> Common Report Var(narrow_types,0) Optimization
> Narrow variables to use the smallest possible type
Nice.
> This would (, for non-public variables)
Many variables will be "public" for compiler since they will be touched
from several .o files within uclibc.
--
vda
More information about the uClibc
mailing list