On Mon, 2018-05-14 at 16:34 +0200, David Brown wrote: > Interesting. Making these sections and then using gc-sections should > only remove code that is not used - LTO should do that anyway.
My guess - expressed in the other e-mail to the list - is that the things LTO cannot remove but --gc-sections can are objects from toolchain library. > Have you tried with -ffunction-sections and not -fdata-sections? It > is > the -fdata-sections that ruins -fsection-anchors - the > -ffunction-sections doesn't have the same kind of cost. Results: - -ffunction-sections + -fdata-sections = 124396 ROM + 3484 RAM - -ffunction-sections = 125168 ROM + 3676 RAM - -ffunction-sections + -fsection-anchors = 125168 ROM + 3676 RAM - -ffunction-sections + -fsection-anchors + -fno-common = 125168 ROM + 3676 RAM Generated executables for the second, third and fourth case are identical - assembly listings for these three cases have no differences at all. I've also tried with -fno-section-anchors, and this makes a minor (negative) difference - 125352 ROM + 3676 RAM. > No, -fsection-anchors has plenty of use for fixed-position eabi code. > ... > The code is clearly bigger and slower, and uses more anchors in the > code > section. > > Note that to get similar improvements with non-static data, you need > "-fno-common" - a flag that I believe should be the default for the > compiler. I cannot reproduce this here ); Don't get me wrong - if there's a "free" way to improve code size/speed with some compiler flags which I did not use previously, then I'm very much interested, however in my particular case the best result (size-wise) I get is with just -ffunction-sections + -fdata-sections. The difference is not huge, but it's also not negligible. Maybe this has to do with different compiler versions we are comparing (4.8 vs 8.1)? I guess this is not LTO (which I did not enable for these measurements), as you did not mention it in your flags... Regards, FCh
