Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add check whether compiler supports -fdata-sections/-ffunction-sections #979

Open
wants to merge 2 commits into
base: vanilla
Choose a base branch
from

Conversation

th-otto
Copy link
Contributor

@th-otto th-otto commented Mar 24, 2024

No description provided.

@OmniBlade
Copy link
Contributor

@hifi could you comment on if we still need these compiler options at all?

@th-otto
Copy link
Contributor Author

th-otto commented Mar 25, 2024

It would be an optimization to reduce the executable size, but imho only makes sense when used in conjunction with --gc-sections when linking. For MiNT (where all libraries are statically linked) that makes a difference of ~1K

@hifi
Copy link
Collaborator

hifi commented Mar 25, 2024

I think those weren't for optimizing but to allow calls to non-existent functions that were optimized out later - this was when we were working on the early version of the code. We probably don't want those if the code compiles without on the CI.

@giulianobelinassi
Copy link
Collaborator

Please remove those flags. According to GCC documentation:

Only use these options when there are significant benefits from doing so. When you specify these options, the assembler and linker create larger object and executable files and are also slower. These options affect code generation. They prevent optimizations by the compiler and assembler using relative locations inside a translation unit since the locations are unknown until link time. An example of such an optimization is relaxing calls to short call instructions. 

hence this is generally a bad idea. If we want to remove dead global functions we should use LTO instead.

@th-otto
Copy link
Contributor Author

th-otto commented May 21, 2024

It makes a difference of ~100k of the executable size in my case. LTO does not help, it does not remove unused functions, and it can't be used with static libraries, since they may be compiled by a different compiler version.

But i have no problem cancelling this PR, i can arrange also to add those flags in my build script.

@giulianobelinassi
Copy link
Collaborator

It makes a difference of ~100k of the executable size in my case. LTO does not help, it does not remove unused functions, and it can't be used with static libraries, since they may be compiled by a different compiler version.

But i have no problem cancelling this PR, i can arrange also to add those flags in my build script.

interesting. Passing -fwhole-program helps?

Also, can you compare the symbols with and without fdata-sections ffunction-sections so we have a list of funcions that are removed during the link process?

@th-otto
Copy link
Contributor Author

th-otto commented May 21, 2024

A log file of the linker about the discarded sections is attached.

discarded.txt.gz

@giulianobelinassi
Copy link
Collaborator

I am approving this since there is no other way in the GNU toolchain to remove those symbols without resorting to LTO, which currently breaks the game.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants