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@xxxxxxxxxxxx> 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@xxxxxxxxxx> wrote:
>> Vyacheslav Egorov <vegorov@xxxxxxxxxxxx> writes:
>>
>>> On Sat, Oct 2, 2010 at 12:37 AM, Ian Lance Taylor <iant@xxxxxxxxxx> 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
>>
>
