This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc moving memory reference across call
Richard Guenther wrote:
> On Mon, Oct 13, 2008 at 4:38 PM, Andrew Haley <aph@redhat.com> wrote:
>> Andrew Pinski wrote:
>>> On Fri, Oct 10, 2008 at 11:14 AM, Andrew Haley <aph@redhat.com> wrote:
>>>> Richard Guenther wrote:
>>>>> On Fri, Oct 10, 2008 at 7:55 PM, Andrew Haley <aph@redhat.com> wrote:
>>>>>> I have some broken code, compiled from Java source.
>>>>>>
>>>>>> It looks like:
>>>>>>
>>>>>> D.843 = &java.text.Collator.class$$;
>>>>>> _Jv_InitClass (D.843);
>>>>>> D.845 = &_CD_java_text_Collator;
>>>>>>
>>>>>> is being turned into:
>>>>>>
>>>>>> D.843 = &java.text.Collator.class$$;
>>>>>> D.845 = &_CD_java_text_Collator;
>>>>>> _Jv_InitClass (D.843);
>>>>> This is always a valid transformation.
>>>>>
>>>>>> i.e. the memory reference is moved to before the call to _Jv_InitClass.
>>>>> There is no memory reference in the above case, it seems just the address
>>>>> of _CD_java_text_Collator is taken.
>>>>>
>>>>> Or maybe I'm missing sth?
>>>> In the RTL code it moves the mem ref, not just the address:
>>>>
>>>> (call (mem:QI (symbol_ref:DI ("_Jv_InitClass") [flags 0x41]
>>>>
>>>> (set (reg/f:DI 95 [ #ref#8#1 ])
>>>> (mem/s/u/f/j:DI (const:DI (plus:DI (symbol_ref:DI ("_CD_java_text_Collator")
>>>> (const_int 16 [0x10])))
>>>>
>>>> is turned to:
>>>>
>>>> (set (reg/f:DI 162 [ #ref#8#1 ])
>>>> (mem/s/u/f/j:DI (const:DI (plus:DI (symbol_ref:DI ("_CD_java_text_Collator")
>>>> (const_int 16 [0x10])))
>>>>
>>>> ...
>>>>
>>>> (call (mem:QI (symbol_ref:DI ("_Jv_InitClass")
>>> Well the mem has a /u on it so it is being marked as MEM_READONLY_P so
>>> it is valid optimization. Why it is being marked with MEM_READONLY_P,
>>> I don't know.
>> I've found the code that's incorrectly marking the decl as TREE_READONLY.
>> It's here:
>>
>> /* If the variable is never written, we can set the TREE_READONLY
>> flag. Additionally if it has a DECL_INITIAL that is made up of
>> constants we can treat the entire global as a constant. */
>>
>> bitmap_and_compl (module_statics_readonly, all_module_statics,
>> module_statics_written);
>> EXECUTE_IF_SET_IN_BITMAP (module_statics_readonly, 0, index, bi)
>> {
>> tree var = get_static_decl (index);
>>
>> /* Ignore variables in named sections - changing TREE_READONLY
>> changes the section flags, potentially causing conflicts with
>> other variables in the same named section. */
>> if (DECL_SECTION_NAME (var) == NULL_TREE)
>> {
>> TREE_READONLY (var) = 1;
>>
>> The decl (called _CD_ppp) is not written by the code we generate, that's true.
>> However, there is a global struct class$, which contains a field which points to
>> _CD_ppp:
>>
>> ppp::class$:
>> .quad vtable for java::lang::Class+16
>> .quad 1074145824
>> .quad _Utf6
>> .value 33
>> .zero 6
>> .quad java::lang::Object::class$
>> .long 2
>> .zero 4
>> .quad _CT_ppp
>> .quad _CD_ppp
>> ...
>>
>> .type _CD_ppp, @object
>> .size _CD_ppp, 16
>> _CD_ppp:
>> .quad 0
>> .quad _Utf5
>>
>> I would expect that this would mean that _CD_ppp has its address taken, and
>> therefore should not be marked as TREE_READONLY.
>
> Right. So I guess ipa-reference doesn't properly treat all TU local globals
> as written-to if the write occurs through a pointer we don't know where it
> points to.
>
> Honza - you recently looked into ipa-reference -- does it try to do the
> right thing with pointer accesses here? I guess it may miss taking addresses
> from inside initializers. Andrew - is this address-taking from ppp::class$
> visible from a DECL_INITIAL or is this hidden behind some magic?
It's a field in the class$ structure. class$ is initialized by creating a
CONSTRUCTOR tree and calling CONSTRUCTOR_APPEND_ELT for each field. The
DECL_INITIAL of class$ points to the CONSTRUCTOR tree.
_CD_pp is an array of void*. These are initialized by DECL_INITIAL too.
InitClass is passed class$$ (not class$) and that has a DECL_INITIAL
that points to class$. As far as I can tell all the types are correct.
Andrew.