Re: Does __attribute__ ((selectany)) make sense now for GCC?

["Gao, Liming" <liming.gao@intel.com>]

Andrew:
  VS has added /Gw option to Optimize Global Data since VS2013. With /Gw option, __declspec(selectany) is not used any more. Now, __declspec(selectany) is kept for old VS tool chain. So, I suggest GCC uses its native optimization option instead of it. 

Thanks
Liming
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Andrew Fish
> Sent: Saturday, May 19, 2018 7:07 AM
> To: Tim Lewis <tim.lewis@insyde.com>
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] Does __attribute__ ((selectany)) make sense now for GCC?
> 
> Tim,
> 
>  VC++ is a strange beast. See C99 support. VC++ seems to do strange things to support non standard hackyness of years past. So the
> only reason I can think of that  __attribute__ ((selectany)) is associated with dead stripping, is doing it correctly broke some chunk of
> code that was required for compatibility. From looking on the VC++ site it seems like COMDAT folding may be required for dead code
> removal, but again this not required to make it work, but to not break old crufty stuff.
> 
> I guess on Windows GCC they could trying to "copy exact" VC++ behavior, but it is most definitely going to be ignored on the
> non-Windows versions.
> 
> The answer from Microsoft on C99 is to use clang :)
> 
> Thanks,
> 
> Andrew Fish
> 
> > On May 18, 2018, at 3:43 PM, Tim Lewis <tim.lewis@insyde.com> wrote:
> >
> > Andrew -
> >
> >
> >
> > I know for Visual Studio it does the same thing for data that /Gy does for
> > code.
> >
> >
> >
> > That is, if the data is unreferenced, then it doesn't get brought it.
> >
> >
> >
> > Maybe link-time code generation has the same effect. That's what I'm curious
> > about.
> >
> >
> >
> > Tim
> >
> >
> >
> > From: afish@apple.com <mailto:afish@apple.com> <afish@apple.com <mailto:afish@apple.com>>
> > Sent: Friday, May 18, 2018 3:39 PM
> > To: Tim Lewis <tim.lewis@insyde.com <mailto:tim.lewis@insyde.com>>
> > Cc: edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
> > Subject: Re: [edk2] Does __attribute__ ((selectany)) make sense now for GCC?
> >
> >
> >
> > Tim,
> >
> >
> >
> > Looks like that is only available on Windows versions of GCC, and is more
> > about compatible behavior.
> >
> >
> >
> > selectany
> >
> > The selectany attribute causes an initialized global variable to have
> > link-once semantics. When multiple definitions of the variable are
> > encountered by the linker, the first is selected and the remainder are
> > discarded. Following usage by the Microsoft compiler, the linker is told not
> > to warn about size or content differences of the multiple definitions.
> >
> > Although the primary usage of this attribute is for POD types, the attribute
> > can also be applied to global C++ objects that are initialized by a
> > constructor. In this case, the static initialization and destruction code
> > for the object is emitted in each translation defining the object, but the
> > calls to the constructor and destructor are protected by a link-once guard
> > variable.
> >
> > The selectany attribute is only available on Microsoft Windows targets. You
> > can use __declspec (selectany) as a synonym for __attribute__ ((selectany))
> > for compatibility with other compilers.
> >
> >
> >
> > What I've noticed with clang/LLVM is the unreferenced globals get removed
> > when you enable link time optimizations.
> >
> >
> >
> > I'd actually ask the opposite question. Does __declspec(selectany) impact
> > dead code removal on current versions of VC++?
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Andrew Fish
> >
> >
> >
> >
> >
> > On May 18, 2018, at 3:22 PM, Tim Lewis <tim.lewis@insyde.com
> > <mailto:tim.lewis@insyde.com <mailto:tim.lewis@insyde.com>> > wrote:
> >
> >
> >
> > In Visual Studio we have __declspec(selectany) to limit the impact of unused
> > data.
> >
> >
> >
> > I see that GCC for Windows has __attribute__ ((selectany)).
> >
> >
> >
> > Should we me using this for GLOBAL_REMOVE_IF_UNREFERENCED in
> > MdePkg\Include\Base.h?
> >
> >
> >
> > Tim
> >
> > _______________________________________________
> > edk2-devel mailing list
> > <mailto:edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
> > <https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel>>
> > https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel>
> >
> >
> >
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
> > https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel