This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
AW: g++keeps unused objects with virtual functions
- From: "Stefan Ehrlich" <stefan dot ehrlich at ehrlich dot eu>
- To: "Richard Biener" <richard dot guenther at gmail dot com>
- 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:23:14 +0200
- Subject: AW: 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>
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?
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