gcc 4.5.1 -fstrict-aliasing and store removal

[Vyacheslav Egorov]

Sorry I provided incorrect version of intermediate representation [bug
does not appear on this one]. Correct one has set_global_context
inlined:

  source.59_37 = (struct GlobalObject * * * {ref-all}) &D.80922;
  D.80925_38 = *source.59_37;
  # DEBUG dest => D.80925_38
  D.80921_39 = *D.80925_38;
  D.80921_64 = D.80921_39;
  D.80921_17 = D.80921_64;
  # DEBUG this => D.80921_17
  # DEBUG value => D.71442_2
  # DEBUG mode => 1
  this.307_40 = (struct Object * *) D.80921_17;
  D.80958_41 = this.307_40 + 31;
  value.308_42 = (struct Object *) D.71442_2;
  *D.80958_41 = value.308_42;

D.80925_38, points-to vars: { }
D.80921_39, points-to vars: { }
this.307_40, points-to vars: { }
D.80958_41, points-to vars: { }

--
Vyacheslav Egorov.



On Mon, Oct 4, 2010 at 11:01 AM, Vyacheslav Egorov <vegorov@chromium.org> wrote:
> 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
>>
>