Re: Why C is much slower than Fortran

Daniel Barker <sokal@holyrood.ed.ac.uk>
30 Apr 1999 22:48:09 -0400

          From comp.compilers

Related articles
Re: Why C is much slower than Fortran sokal@holyrood.ed.ac.uk (Daniel Barker) (1999-04-18)
Re: Why C is much slower than Fortran telken@sgi.com (Thomas Elken) (1999-04-29)
Re: Why C is much slower than Fortran sokal@holyrood.ed.ac.uk (Daniel Barker) (1999-04-30)
Re: Why C is much slower than Fortran harley@corton.inria.fr (Robert Harley) (1999-05-03)
Re: Why C is much slower than Fortran hrubin@stat.purdue.edu (1999-05-09)
Re: Why C is much slower than Fortran terryg@uswest.net (1999-05-16)
Re: Why C is much slower than Fortran gneuner@dyn.com (1999-05-16)
Re: Why C is much slower than Fortran reid@micro.ti.com (Reid Tatge) (1999-05-20)
Re: Why C is much slower than Fortran jhallen@world.std.com (1999-05-29)
[10 later articles]
| List of all articles for this month |

From: Daniel Barker <sokal@holyrood.ed.ac.uk>
Newsgroups: comp.lang.c++,comp.compilers
Date: 30 Apr 1999 22:48:09 -0400
Organization: Edinburgh University
References: <3710584B.1C0F05F5@hotmail.com> <7esvkr$v8g$1@camel29.mindspring.com> <37122569.BF79CD19@hotmail.com> <3712311D.BA9027D4@hotmail.com> <7etenl$nk5$1@alexander.INS.CWRU.Edu> 99-04-048 99-04-105
Keywords: C, performance

[not posted to comp.lang.fortran]


On 29 Apr 1999, Thomas Elken wrote:


[snip]
> The definition of *some* of the alias options for the MIPSpro C/C++
> compiler are:
>
> Suboptions Action
>
> alias=name Specifies the pointer aliasing model to be used. By
> specifiying one of the following for name, the compiler
> is
> able to make assumptions throughout the compilation:
>
> name Assumption
>
> TYPED or NO_TYPED TYPED specifies that pointers of
> distinct base types are assumed to
> point to distinct, non-overlapping
> objects.
>
> NO_TYPED specifies that pointers to
> different base types may point to
> the same object.
>
> (C and C++ only)
[snip]


Is -OPT:alias=typed safe if an array of type T is is accessed through both
a pointer to T and a pointer to unsigned char? It could also be accessed
through a pointer to void, cast to either or both of these. All of this is
allowed in C, and might occur in bit-manipulating code. For example:


#include <stddef.h>


void f(unsigned int *ip, int lim, size_t *used, unsigned char byte_val)
/* for each element i of the lim-element array whose first element is
  * pointed to by ip, set the first used[i] bytes to byte_val and the
  * remaining bytes to zero; used[i] must lie in the interval
  * [0, sizeof(unsigned int)]; the resulting value of ip[i] is
  * implementation-defined */
{
    int i; /* loop counter */
    size_t j; /* loop counter */
    unsigned char *cp; /* byte pointer */


    cp = (unsigned char *) ip;
    for (i = 0; i < lim; i++)
    {
        ip[i] = 0U; /* set all bytes to zero */
        /* set some of the bytes to byte_val */
        for (j = 0; j < used[i]; j = j + sizeof(unsigned int))
            cp[j] = byte_val;
    }
}


I believe the above is entirely standard and allowed in C, unless I have
made some mistake. My question, which I have wondered about before because
I find the man page too brief, is whether this kind of aliasing is allowed
when invoking MIPS C as "cc -OPT:alias=typed".


Daniel Barker.
[C lets you alias anything to anything, and that does indeed cause
optimization problems. The C9X draft has a "restrict" keyword that lets
you assure the compiler that a pointer doesn't have aliasing problems.
I presume the MIPS hack says that only data of the same type can be
aliased, sort of the same thing here. -John]



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.