This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Proposal
- To: gcc at gcc dot gnu dot org
- Subject: Proposal
- From: Frank Klemm <pfk at fuchs dot offl dot uni-jena dot de>
- Date: Sat, 15 Sep 2001 20:41:21 +0200 (CEST)
- >Received: (from pfk@localhost)by fuchs.offl.uni-jena.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id UAA04064for gcc@gcc.gnu.org; Sat, 15 Sep 2001 20:41:22 +0200
- Reply-To: pfk at RZ dot uni-jena dot de
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