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

Stock function with recursion not removed if not used #358

Closed
Kailo97 opened this issue Aug 27, 2019 · 1 comment
Closed

Stock function with recursion not removed if not used #358

Kailo97 opened this issue Aug 27, 2019 · 1 comment

Comments

@Kailo97
Copy link
Contributor

Kailo97 commented Aug 27, 2019

Bug: So, i wrote some lib functions that required using of recursion call. Functions not used but stay to compile (not small functions, make +8k bytes to plugin code).
Tested with 1.9.0.6270, 1.10.0.6435 and latest sourcepawn master branch build.

// This function not called anywhere else
stock void MyStock()
{
	MyStock();
}
dvander added a commit that referenced this issue Sep 10, 2019
…embly.

The two-pass system in the compiler is able to roughly guess which
functions are not used, but it's a poor guess. Stocks called by other
stocks, including recursive functions, all get compiled in. We can fix
this by traversing the call graph to determine the actual live set.

Note, the assembler now skips functions with uDEFINED but not uPUBLIC.
uDEFINED is cleared by delete_symbols, so it looks like a pointless
check.

This patch shaves about 10% off some .smx files sampled from the
SourceMod tree.

Bug: issue #358
Test: manual test
dvander added a commit that referenced this issue Sep 10, 2019
For some reason, natives had a weird relationship with the assembler.
The code generator assigned an address based on a global counter, and
then the assembler was responsible for building the table in the same
order. (Similar nonsense exists with the staging counter, but we'll save
that for another day.)

Instead, emit sysreq instructions by name as we do for the call
instruction. This allows us to build the table during code generation,
simplifying another piece of the assembler pipeline.

Bug: issue #358
Test: manual test
dvander added a commit that referenced this issue Sep 10, 2019
…embly.

The two-pass system in the compiler is able to roughly guess which
functions are not used, but it's a poor guess. Stocks called by other
stocks, including recursive functions, all get compiled in. We can fix
this by traversing the call graph to determine the actual live set.

Note, the assembler now skips functions with uDEFINED but not uPUBLIC.
uDEFINED is cleared by delete_symbols, so it looks like a pointless
check.

This patch shaves about 10% off some .smx files sampled from the
SourceMod tree.

Bug: issue #358
Test: manual test
dvander added a commit that referenced this issue Sep 10, 2019
…embly.

The two-pass system in the compiler is able to roughly guess which
functions are not used, but it's a poor guess. Stocks called by other
stocks, including recursive functions, all get compiled in. We can fix
this by traversing the call graph to determine the actual live set.

Note, the assembler now skips functions with uDEFINED but not uPUBLIC.
uDEFINED is cleared by delete_symbols, so it looks like a pointless
check.

This patch shaves about 10% off some .smx files sampled from the
SourceMod tree.

Bug: issue #358
Test: manual test
dvander added a commit that referenced this issue Sep 10, 2019
…embly.

The two-pass system in the compiler is able to roughly guess which
functions are not used, but it's a poor guess. Stocks called by other
stocks, including recursive functions, all get compiled in. We can fix
this by traversing the call graph to determine the actual live set.

Note, the assembler now skips functions with uDEFINED but not uPUBLIC.
uDEFINED is cleared by delete_symbols, so it looks like a pointless
check.

This patch shaves about 10% off some .smx files sampled from the
SourceMod tree.

Bug: issue #358
Test: manual test
@dvander dvander closed this as completed Sep 10, 2019
@dvander
Copy link
Member

dvander commented Sep 10, 2019

Thanks for the report, this was a good catch.

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

No branches or pull requests

2 participants