gcc 4.5.1 -fstrict-aliasing and store removal

[Vyacheslav Egorov]

So now I am trying to read dump of alias information produced by
-fdump-tree-alias for my problematic translation unit and here is what
I see:

void Genesis::HookUpGlobalProxy(Handle<GlobalObject> inner_global,
                                Handle<JSGlobalProxy> global_proxy) {
 // ...
 inner_global->set_global_context(*global_context());
// ...
}

  source.55_37 = (struct GlobalObject * * * {ref-all}) &D.79958;
  D.79961_38 = *source.55_37;
  # DEBUG dest => D.79961_38
  D.79957_39 = *D.79961_38;
  D.79957_43 = D.79957_39;
  D.79957_17 = D.79957_43;
  v8::internal::GlobalObject::set_global_context (D.79957_17, D.71929_2, 1);

where

D.79957_17, points-to vars: { }

if I am reading this correctly this means exactly what we discussed
earlier: GCC decided that pointer to GlobalObject stored inside handle
inner_global is not aliasing anything and then (after inlining
set_global_context) removed writes to
through it.

I will continue digging this.

--
Vyacheslav Egorov


On Sat, Oct 2, 2010 at 1:15 AM, Ian Lance Taylor <iant@google.com> wrote:
> Vyacheslav Egorov <vegorov@chromium.org> writes:
>
>> On Sat, Oct 2, 2010 at 12:37 AM, Ian Lance Taylor <iant@google.com> wrote:
>>> Well, also, you need to allocate Object* values using malloc or placement new, not, say, new
>>> char[].
>>
>> We use a custom allocators which do not rely on any of these [we mmap
>> pages and treat pieces of mmap'ed pages as objects]. Is this a
>> problem?
>
> That should be fine.  Anything which essentially acts like malloc should
> be fine.  The difference is that new char[] returns memory which already
> has a type, and malloc or mmap do not.
>
> Ian
>