Jordan Justen [mailto:jordan.l.jus...@intel.com] wrote:
]Sent: Friday, July 10, 2015 02:24 AM ]To: edk2-devel@lists.sourceforge.net; Scott Duplichan ]Subject: Re: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables ] ]On 2015-07-08 19:31:09, Scott Duplichan wrote: ]> Bruce Cran [mailto:br...@cran.org.uk] wrote: ]> ]> ]Sent: Wednesday, July 08, 2015 05:12 PM ]> ]To: edk2-devel@lists.sourceforge.net ]> ]Subject: Re: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables ]> ] ]> ]On Wed, Jul 08, 2015 at 10:43:38PM +0200, Laszlo Ersek wrote: ]> ] ]> ]> I think it would make a difference if -flto *actually* worked, but from ]> ]> a quick google search, I think it either doesn't work with gcc-4.8 at ]> ]> all, *or* the edk2 build system would have to use FLTO-aware binutils ]> ]> and linker wrappers (or parameters). I have no clue how to set that up. ]> ]> So for now we'll have to stick with MDEPKG_NDEBUG I guess. ]> ] ]> ]I've been trying to get -flto working this week, but without success (yet!). ]> ]I'm currently running into a problem of ld (built from source) apparently not ]> ]knowing about the lto plugin (and passing the liblto.so file via -plugin causes ]> ]an assert failure), but I'll keep trying. ]> ]> Last year I spent some time to get gcc -flto working properly with EDK2. ]> At that time, the people here were busy with other things and there didn't ]> seem to be a lot of interest in gcc link time optimization. So I never ]> submitted a patch. Maybe it is time to revive this effort. Here is what I ]> found: ]> ]> http://notabs.org/uefi/gcc-lto.htm ]> ]> So 6 conditions need to be met for ghcc link time optimization to work ]> properly with EDK2: ]> ]> 1) Add -flto to the compile flags ]> 2) Use gcc to launch ld instead of invoking ld directly ]> 3) Include the compile flags on the link command line ]> 4) Use gcc-ar in place of ar when building static libraries ]> 5) Library code that resolves helper function calls generated by the compiler must be compiled ]without the -flto flag ]> 6) These libraries must be prefixed with -Wl,-plugin-opt=-pass-through= on the link command line. ]> ]> A patch from late 2014 is here: ]> http://sourceforge.net/projects/edk2developertoolsforwindows/files/Patches/Link%20Time%20Optimization/ ] ]BaseTools/Contributions.txt (Contributed-under...) ] ]If you don't submit it edk2-devel, and continue to follow up on it, ]then work can easily slip through the cracks. ] ]That said, I've spent a little time looking at your work, so it's not ]true that there was no interest. But, if you have something that is ]*actually working* for DuetPkg, EmulatorPkg and OvmfPkg, can you put ]together a patch series? The patch isn't ready for review. One reason is that it exposes a problem that has no simple solution that I can find. A BaseTools change may be needed. Link time code generation allows gcc to warn about things that it otherwise can't. With -flto, gcc warns about: extern const VOID* _gPcd_FixedAtBuild_PcdShellSupplier[]; AutoGen.c:207:15: note: previously declared here GLOBAL_REMOVE_IF_UNREFERENCED const UINT16 _gPcd_FixedAtBuild_PcdShellSupplier[7] = {69, 68, 75, 32, 73, 73, 0 }; Both definitions are generated so they can't easily be changed. This slight inconsistency in the array definition stops the build because of warnings as errors. For this -flto proof of concept experiment, I disable warning as errors. But the problem needs to be resolved before a patch can be submitted. It was discussed in a thread titled "Status of gcc link time optimization for EDK2 use". Sergey made a python patch, but as I remember it didn't quite fix every occurrence. ]I don't see how we can manage 5 & 6 with our current BaseTools. How ]did you manage it? Searching for 'pass-through' in your patch doesn't ]yield any results. I punted and omitted -flto for that case. It is only a serious problem for ARM: "While making the EDK2 build meet requirement 5 is easy, the same is not true for requirement 6 in some cases. For example, the ARM build resolves compiler generated helper function calls with CompilerIntrinsicsLib.lib and BaseStackCheckLib.lib. The path to these libraries varies with the package name and build options. Without a significant modification to the EDK2 build tools, there is no way to generate the requires prefixed path for use on the linker command line. This limitation affects ARM builds the most because gcc ARM code uses more compiler generated helper function calls than other target architectures. For this reason, link time optimization is not enabled for ARM in the gcc LTO EDK2 patch. The use of compiler generated helper function calls is kept to a minimum in x86 code. For the IA32 builds the compiler generates a floating point helper call when building stdlib. The patch disables link time optimization for IA32 stdlib to avoid the -Wl,-plugin-opt=-pass-through= requirement." I will update the patch to work with the current EDK2 code. Here are another couple of things to decide. 1) Which gcc version(s) get -flto? Probably 4.9 and later make sense. 2) Use of gcc -flto probably needs to be optional. We could make two tool chain definitions, such as GCC49 and GCC49LTO. But that creates a lot of duplication in an already big template file. For the proof of concept experiment, -flto can be disabled by setting an environment variable. ]Thanks, ] ]-Jordan ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
