This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: g++keeps unused objects with virtual functions
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Stefan Ehrlich <stefan dot ehrlich at ehrlich dot eu>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, GCC Development <gcc at gcc dot gnu dot org>, zlynx at acm dot org
- Date: Wed, 8 Apr 2015 13:26:48 +0200
- Subject: Re: g++keeps unused objects with virtual functions
- Authentication-results: sourceware.org; auth=none
- References: <55D79922DFF3F742B9F3F1A814CA6B7518FDEB at atvie01vm001 dot ehrlich dot lan> <43BCCAF1-C7A3-4282-A9BA-011E9DB91AD7 at gmail dot com> <55D79922DFF3F742B9F3F1A814CA6B7518FDEC at atvie01vm001 dot ehrlich dot lan> <CAFiYyc2y9zi6s=J0jW3zY206MYUWbqGQRFUuDmrXgKaAoZxnwA at mail dot gmail dot com> <20150408085401 dot GA27929 at kam dot mff dot cuni dot cz> <20150408085939 dot GB27929 at kam dot mff dot cuni dot cz> <55D79922DFF3F742B9F3F1A814CA6B7518FDED at atvie01vm001 dot ehrlich dot lan> <CAFiYyc3LH41UAYSnUUUpyjZBMdgV22WZjXpp8VqCvxCwhs0XxA at mail dot gmail dot com> <55D79922DFF3F742B9F3F1A814CA6B7518FDEE at atvie01vm001 dot ehrlich dot lan>
On Wed, Apr 8, 2015 at 1:23 PM, Stefan Ehrlich
<stefan.ehrlich@ehrlich.eu> wrote:
> Dear Richard,
>
> The optimization step for doing it does already exist --> it is used for stack variables/objects, but unfortunately not for the global ones.
> The same optimization should work for the global variables/objects, too. Or am I wrong?
Well - analysis to prove that global objects are unused is more
difficult, so yes, you are wrong.
Richard.
> Stefan
>
>
> -----UrsprÃngliche Nachricht-----
> Von: Richard Biener [mailto:richard.guenther@gmail.com]
> Gesendet: Mittwoch, 08. April 2015 12:14
> An: Stefan Ehrlich
> Cc: Jan Hubicka; GCC Development; zlynx@acm.org
> Betreff: Re: g++keeps unused objects with virtual functions
>
> On Wed, Apr 8, 2015 at 11:59 AM, Stefan Ehrlich <stefan.ehrlich@ehrlich.eu> wrote:
>> But without the virtual keyword the global object never read is completely removed, so the statement "[...]but we don't have any pass removing stores to globals never read[...]" is only true with virtual functions.
>> When I create the object on the stack, the optimization removes the object even with virtual functions completely (resp. partially when only a part of the object is used).
>>
>> The SomeData is removed completely, when created on stack (regardless I call the function virtFunction) - when the commented out object NotUsedObject is getting back into the code, the vtable, the virtual function, and the 100 ints are present in the executable.
>>
>> class CObject
>> {
>> public: virtual void virtFunction() {}
>> public: int SomeData[100];
>> };
>>
>> //CObject NotUsedObject;
>>
>> int main()
>> {
>> CObject UsedObject;
>> UsedObject.virtFunction();
>> return 0;
>> }
>>
>> So what can I do?
>
> Nothing (well, improve GCC!).
>
> Richard.
>
>> Stefan
>>
>> -----UrsprÃngliche Nachricht-----
>> Von: Jan Hubicka [mailto:hubicka@ucw.cz]
>> Gesendet: Mittwoch, 08. April 2015 11:00
>> An: Jan Hubicka
>> Cc: Richard Biener; Stefan Ehrlich; GCC Development; zlynx@acm.org
>> Betreff: Re: g++keeps unused objects with virtual functions
>>
>>> > which shows how the global objects initialization keeps things live.
>>> > Early optimization turns it into
>>> >
>>> > (static initializers for t.C) ()
>>> > {
>>> > <bb 2>:
>>> > NotUsedObject._vptr.CObject = &MEM[(void *)&_ZTV7CObject + 16B];
>>> > return;
>>> >
>>> > }
>>> >
>>> > but we don't have any pass removing stores to globals never read.
>>> > IPA reference computes this in some way but doesn't get to export
>>> > this in a reasonable way - its transform stage could DSE those
>>> > though.
>>>
>>> We have write only variable detection but
>>> > NotUsedObject/4 (CObject NotUsedObject) @0x7f70d41fe580
>>> > Type: variable definition analyzed
>>> > Visibility: public
>>> > References:
>>> > Referring: _Z41__static_initialization_and_destruction_0ii/9 (addr)
>>> > Availability: not-ready
>>> > Varpool flags:
>>>
>>> it stops on fact believing that address of NotUsedObject is taken.
>>> Why it is not considered to be load?
>>
>> Too early dump I guess. At mainline I get empty constructor:
>> .type _GLOBAL__sub_I_NotUsedObject, @function
>> _GLOBAL__sub_I_NotUsedObject:
>> .LFB6:
>> rep ret
>>
>> not ideal, but still an improvement ;) The problem is that write only
>> var is removed only at late optimization and then it is too late to remove the unreachable function.
>>
>> Honza
>>>
>>> Honza