Dear Richard, Is there any way to get the information about the referencing symbols out of/to the map file? The -cref flag does not provide useful information about the referenced symbols. Something like this (example of an IAR linker map file).
ENTRY ADDRESS REF BY ===== ======= ====== call_count 00100128 next_counter (common) ENTRY ADDRESS REF BY ===== ======= ====== main 00008138 __main (?CSTARTUP) Lg Stefan -----Ursprüngliche Nachricht----- Von: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] Im Auftrag von Stefan Ehrlich Gesendet: Mittwoch, 08. April 2015 13:32 An: Richard Biener Cc: Jan Hubicka; GCC Development; zl...@acm.org Betreff: AW: g++keeps unused objects with virtual functions That means, that there is no chance to find this in the next future GCC releases :-( But anyway... Thanks so far Stefan PS: Hope dies last -----Ursprüngliche Nachricht----- Von: Richard Biener [mailto:richard.guent...@gmail.com] Gesendet: Mittwoch, 08. April 2015 13:27 An: Stefan Ehrlich Cc: Jan Hubicka; GCC Development; zl...@acm.org Betreff: Re: g++keeps unused objects with virtual functions On Wed, Apr 8, 2015 at 1:23 PM, Stefan Ehrlich <stefan.ehrl...@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.guent...@gmail.com] > Gesendet: Mittwoch, 08. April 2015 12:14 > An: Stefan Ehrlich > Cc: Jan Hubicka; GCC Development; zl...@acm.org > Betreff: Re: g++keeps unused objects with virtual functions > > On Wed, Apr 8, 2015 at 11:59 AM, Stefan Ehrlich <stefan.ehrl...@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:hubi...@ucw.cz] >> Gesendet: Mittwoch, 08. April 2015 11:00 >> An: Jan Hubicka >> Cc: Richard Biener; Stefan Ehrlich; GCC Development; zl...@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
