On Mon, Oct 13, 2008 at 4:38 PM, Andrew Haley <[EMAIL PROTECTED]> wrote:
> Andrew Pinski wrote:
>> On Fri, Oct 10, 2008 at 11:14 AM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>>> Richard Guenther wrote:
>>>> On Fri, Oct 10, 2008 at 7:55 PM, Andrew Haley <[EMAIL PROTECTED]> 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?
Thanks,
Richard.
