gcc 4.5.1 -fstrict-aliasing and store removal

[Vyacheslav Egorov]

On Fri, Oct 1, 2010 at 9:55 PM, Ian Lance Taylor <iant@google.com> wrote:
> Sure, but the compiler can prove 1) p points to a local variable and 2)
> the local variable is not used.

Hmm. I think I am starting to get a sketchy understanding [stores to
local variable with no aliasing loads can be removed], but I am still
a bit confused.

I will try to read places in GCC source where actual alias analysis
happens. This should give me a better understanding of mechanics and
underlying assumptions.

I am still pretty sure that stores in function [like init] accepting
pointers from outside can be removed because compiler can't prove that
there will be no loads from the same memory.

> Again what matters is that all accesses to a particular object use the
> same type.  Casting to other pointers doesn't matter as long as you
> don't actually use those pointers.  In this case I don't know whether
> you use them or not.  I assume there are no virtual functions here.  If
> you have an Object* po, and you cast it to a Foo* pf, and you then say
> pf->x, that should be OK with regard to the aliasing rules.

Let me provide you a bit more detail: we have this hierarchy of
classes with Object class as a root and all other (e.g. GlobalObject,
Context) inheriting from it. This classes have no members, no virtual
functions, no constructors, no destructors. They are never constructed
as values. We only have variables of pointer types like Context* or
Object**. On this variables we call methods:

Context* ctx = foo();
ctx->set_bar(ctx);

Inside setters/getters we treat this pointer kinda like an Object** pointer:

#define FIELD_ADDR(p, offset) \
 (reinterpret_cast<byte*>(p) + offset - kHeapObjectTag)

#define WRITE_FIELD(p, offset, value) \
 (*reinterpret_cast<Object**>(FIELD_ADDR(p, offset)) = value)

So set_bar() method would be implemented like

void Context::set_bar(Context* ctx) {
  WRITE_FIELD(this, kBarFieldOffset, ctx);
}

We only load/store to/from object "fields" through this kind of casts.

Does it look OK to you?

If it looks OK then removal of such write might mean bug in GCC. I
will return to my attempts to construct a small example.

--
Vyacheslav Egorov