This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: DCE enhancement to delete dead vptr assignment
On Fri, Apr 16, 2010 at 3:53 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
> On 04/16/2010 07:01 PM, Xinliang David Li wrote:
>>
>> On Fri, Apr 16, 2010 at 9:29 AM, Steven Bosscher<stevenb.gcc@gmail.com>
>> ?wrote:
>>>
>>> + ? ?{
>>> + ? ? ?/* Initialization of the vptr field for the same object this
>>> + ? ? ? ? destructor is operating on won't be live out of the function
>>> + ? ? ? ?if it is not used within the function, so do not treat them
>>> + ? ? ? ?as a hidden global store. ?*/
>>> + ? ? ?if (lang_hooks.decls.is_decl_dtor (current_function_decl))
>>> + ? ? ? ?{
>>
>> Do you want me to wrap it in a wrapper function?
>
> No, it should be avoided altogether.
>
> In particular:
>
> - one langhook you add, is_polymorphic_type_p, is unused
Ok -- this one is actually for another patch of mine that handles
vptr/vtbl aliasing.
>
> - one, is_global_delete_fndecl_p type can be replaced with an attribute (if
> it is safe WRT redefinitions).
That is ideal -- any plan to get rid of langhooks altogether?
>
> - one, cp_is_vptr_field_p, need not be a langhook at all as far as I could
> see as it only accesses common fields (if I'm wrong, you may be masking
> other bugs).
>
> This leaves is_decl_dtor. ?I think the front-end should add one dummy GIMPLE
> statement (e.g. a call to a builtin with a special attribute and that expand
> to nothing) that says "treat this datum as dead". ?This way, this special
> case can fall in the normal dataflow scheme, as Richard suggested.
Front-end should not/can not be involved directly -- the vptr field
store is inserted in the dtor of the derived class before calling the
base class dtor. Without/before (e.g. base class dtor is defined in a
different module) seeing the base class dtor which may or may not
empty (can have aliased stmts).
David
>
> BTW, is_killed_by_delete is called rarely---though you never know about
> pathological cases---but it is slow!
>
>>> We should not be calling lang hooks from the optimizers.
>>>
>>> How would this work with inter-language IPA?
>>
>> When can the tree structure be flatten out so that there is no
>> language specific attributes? Until then, what is the solution?
>> Inter-language IPA? When do we plan to have full support of that?
>
> Already now having optimizations that pass with g++ but fail with LTO is
> considered bad.
>
> Paolo
>