This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Proposal



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 Gren
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]