On Sat, Jun 07, 2008 at 07:39:54AM +0200, Denys Vlasenko wrote: >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?
Not needed for me, so no but thanks. >> 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. if somebody would implement it, yes. >> This would (, for non-public variables) > >Many variables will be "public" for compiler since they will be touched >from several .o files within uclibc. If they are hidden then they are not public, i think. _______________________________________________ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
