On Friday 06 June 2008 14:50, Bernhard Fischer wrote: > On Thu, Jun 05, 2008 at 08:24:45PM -0700, [EMAIL PROTECTED] 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 _______________________________________________ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
