From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frank Klemm To: gcc@gcc.gnu.org Subject: Proposal Date: Sat, 15 Sep 2001 11:45:00 -0000 Message-id: <200109151841.UAA04064@fuchs.offl.uni-jena.de> X-SW-Source: 2001-09/msg00600.html I propose a websites with the following contents: - gcc language extentions - possible performance enhancements 2) - warnings of the compiler 3) - libc related issues - gcc language extentions (future) 1) - possible performance enhancements (future) - warnings of the compiler (future) - libc related issues (future) - gcc language extentions (decline) - possible performance enhancements (decline) - warnings of the compiler (decline) - libc related issues (decline) Every proposal is discussed in the mailing list and is classified into: - should be done in the next time - future improvement, useful, but too difficult to implement in the next time - decline, not so useful, too many problems, too difficult to implement - gcc language extentions: Extention of the language C or C++ - where are performance improvements possible - additional or superfluous warnings (or errors) - libc related issues, missing library function, problems, bugs and flaws Performance test suite - list of small *.inc files containing a small piece of code 4) - a body function which does all the rest - a table for the Duron/Athlon family, for the PII/PIII/Celeron family and one for the P4 family - a table for -O, -O2 and for -O3 - task is to show improvements and deterioration in the compilers code Test# Description operations/µs 2.95.2 3.00 3.01 3.02 ------------------------------------------------------------- 137 round test (int)floor() 11.5 11.9 11.8 191 138 foobar 91 75 75 92 1) ****************************************************************************** Separator for long number ~~~~~~~~~~~~~~~~~~~~~~~~~ The bigger the number the more difficult is it to decipher large numbers: 0xFFFFFFFFFFFFFFFC 1000000000000 0x0FFFFFFFFFFFFFFC 10000000000000 3.14159265358979 12768487.0 Ada 83 and Ada 95 allows '_' in numbers to separate groups of numbers: 0xFFFF_FFFF_FFFF_FFFC 1_000_000_000_000 0x0FFF_FFFF_FFFF_FFFC 10_000_000_000_000 3.14159_26535_8979 12_768_487.0 The '_' is allowed at every position between digits, but it is recommend to use it in the way above. integral hexadecimal numbers: 4 digits decimal integral part of numbers: 3 digits fractional part of numbers: 5 digits May be we should introduce this is C too. It is not allowed to compose numbers with '_' inside of macros. #define MILLION _MERGE5 ( 1, _, 000, _, 000 ) This allows easily to write a filter to generate C89 or C99 files. Problems ~~~~~~~~ The are no problems with foreward compatibilty, syntax always generates a syntax error on standard C99 compilers. Programs are not backward compatible at all. gcc should contain a filter to convert files with '_' inside of numbers into C89 or C99 files. gcc -_ program.c > filtered/program.c Pros ~~~~ It makes C and C++ programs easier to read It is easier to find errors. Cons ~~~~ Bad backward compatibility. There are other writing possible: 1000000000000 = 1_000_000_000_000 = 1000 * 1000 * 1000 * 1000 0xFFFFFFFFFFFFFF00 = 0xFFFF_FFFF_FFFF_FF00 = ~0x100 But it is easy to introduce other bugs with these writings 2 **************************************************************************** Command line ---------------------------------------- gcc302 -O3 -fomit-frame-pointer C code ---------------------------------------------- unsigned long long x; void main ( void ) { x >>= 32; return 0; } Assembler code --------------------------------------- main: pushl %ebp <------ movl %esp, %ebp <------ subl $8, %esp <------ movl x+4, %eax xorl %edx, %edx andl $-16, %esp <------ movl %edx, x+4 movl %eax, x movl %ebp, %esp <------ xorl %eax, %eax popl %ebp <------ ret Suggested optimized Assembler code: ------------------------------ // -O2 main: movl x+4, %eax xorl %edx, %edx movl %eax, x movl %edx, x+4 xorl %eax, %eax ret // -Os main: movl $x, %ecx xorl %edx, %edx movl 4(%ecx), %eax movl %edx, 4(%ecx) movl %eax, (%ecx) xorl %eax, %eax ret // -Oss main: movl $x+4, %ecx xorl %eax, %eax movl (%ecx), %edx movl %eax, (%ecx) movl %edx, -4(%ecx) ret Current version: 33 byte proposed -O2: 21 byte proposed -Os: 18 byte proposed -Oss: 15 byte Remarks ---------------------------------------------- Stack alignment of gcc 3.02 is really a nasty thing. It blows up code, it slows down code. It is really a pain. Before doing alignment on stack there should be clarified: - who is responsable for aligning (caller / called) - when it have a chance to speed up code (you need at least 64 bit items) - what other conditions are needed to speed up code (manipulating %esp decreases speed of push/pop/mov) Proposal ------------------------------------------------ - A caller should never align the stack - A function aligns the stack if there are arrays of 64 bit local variables on the stack - If there are many 64 bit local variables on stack the function may align the stack - functions arguments can be copied to such a local place if the variable is often used and not copied to a FPU register. 3 *************************************************************** Problem ~~~~~~~ Using of operator <=, >= or != although only one of the two partial conditions is possible: unsigned int x; if ( x <= 0 ) { ... } unsigned char c; if ( c != 255 ) { ... } This is often a hint that the code is wrong. It should be possible to genarte a warning for such code. 4 ******************************************************************* /* * Rounding floats to integers, always rounding to -inf. */ /* Argument is the ca. execution time on a 1 GHz computer in milliseconds */ float test0137_float [1000]; int test0137_int [1000]; struct result test0137_run ( unsigned int ms ) { struct result ret; unsigned int i; unsigned int j; unsigned int k; for ( k = 0; k < ms; k++ ) for ( i = 0; i < 200000; i++ ) for ( j = 0; j < 1000; j++ ) test0137_int [j] = (int) floor (test0137_float [j]); ret.name = "round test (int)floor()"; ret.ops = 200.e6 * ms; return ret; } void test0137_init ( void ) { } /* The rest will be done by the program around */ -- Mit freundlichen Grüßen Frank Klemm eMail | pfk@uni-jena.de home: pfk@schnecke.offl.uni-jena.de | fingerprint: CDBB D7AE 0488 96B2 E0F9 98C2 1441 051C phone | +49 (3641) 64-2721 home: +49 (3641) 390545 sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany