This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: LTO vs GCC 8
On May 11, 2018 5:49:44 PM GMT+02:00, Freddie Chopin <freddie_chopin@op.pl> wrote:
>On Fri, 2018-05-11 at 13:06 +0200, David Brown wrote:
>> For the Cortex-M devices (and probably many other RISC targets),
>> -fdata-sections comes at a big cost - it effectively blocks
>> -fsection-anchors and makes access to file-static data a lot bigger.
>> People often use -fdata-sections and -ffunction-sections along with
>> -Wl,--gc-sections with the aim of removing unused code and data (and
>> thus saving space, useful on small devices) - I would expect LTO
>> would
>> manage that anyway. The other purpose of these is to improve
>> locality
>> of reference - again LTO should do that for you. But even without
>> LTO,
>> I find the cost of -fdata-sections high compared to -fsection-
>> anchors.
>
>Unfortunatelly having LTO doesn't make -ffunction-sections + -fdata-
>sections + --gc-sections useless.
>
>My test project compiled:
>- without LTO and without these attributes - 150824 B ROM + 4240 B RAM
>- with LTO and without these attributes - 133812 B ROM + 4208 B RAM
>- without LTO and with these attributes - 124456 B ROM + 3484 B RAM
>- with LTO and with these attributes - 120280 B ROM + 3680 B RAM
>
>As you see these attributes give much more than LTO in terms of size.
>
>As for the -fsection-anchors I guess this has no use for non-PIC code
>for arm-none-eabi. Whether I use it or not, the sizes are identical.
That's an interesting result. Do you have any non-LTO objects? Basically I'm curious what ld eliminates that gcc with LTO doesn't.
As to a workaround for the ld bug you can try keeping all .debug_* sections. IIRC 2.30 has the bug fixed (on the branch).
Richard.
>Regards,
>FCh