[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] More on aliasing.

From: Peter Keller
Subject: Re: [Chicken-users] More on aliasing.
Date: Mon, 8 Jul 2002 15:39:12 -0500
User-agent: Mutt/1.2i

On Mon, Jul 08, 2002 at 03:34:37PM -0500, Peter Keller wrote:
> > I was just wondering if this definition you mentioned was strict enough to
> > prevent the compiler from putting (register sized) unions into machine
> > registers even when their address was never actually used. If so, then
> > obviously this restriction could really slow down union code vs. the
> > equivalent casting code. I hope this is the case, otherwise the strict
> > aliasing optimization switch wouldn't be very useful for this kind of
> > code.
> I don't know if it is strict enough without digging around in some language
> specs and trying out some test code to see what the assembly looks like.
> I guess if it did slow down execution a little, you'd have to balance the
> readability and debuggability of the generated code with the speed of it.

Here is strict-aliasing from the gcc manual:


    Allows the compiler to assume the strictest aliasing rules applicable
    to the language being compiled. For C (and C++), this activates
    optimizations based on the type of expressions. In particular, an
    object of one type is assumed never to reside at the same address
    as an object of a different type, unless the types are almost the
    same. For example, an unsigned int can alias an int, but not a void*
    or a double. A character type may alias any other type.

    Pay special attention to code like this:

union a_union {
  int i;
  double d;

int f() {
  a_union t;
  t.d = 3.0;
  return t.i;

    The practice of reading from a different union member than the one
    most recently written to (called "type-punning") is common. Even
    with -fstrict-aliasing, type-punning is allowed, provided the memory
    is accessed through the union type. So, the code above will work as
    expected. However, this code might not:

int f() {
  a_union t;
  int* ip;
  t.d = 3.0;
  ip = &t.i;
  return *ip;

    Every language that wishes to perform language-specific alias analysis
    should define a function that computes, given an tree node, an alias
    set for the node. Nodes in different alias sets are not allowed to
    alias. For an example, see the C front-end function c_get_alias_set.


So it looks like if you were to use unions, you'd have to be careful about
it and not use pointers to members in the union.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]