Skip to content

[K/N] Make kotlin-remove-sp a proper LLVM pass#6301

Open
Alexander Shabalin (projedi) wants to merge 3 commits into
masterfrom
alshabalin/KT-84060/port-kotlin-remove-sp
Open

[K/N] Make kotlin-remove-sp a proper LLVM pass#6301
Alexander Shabalin (projedi) wants to merge 3 commits into
masterfrom
alshabalin/KT-84060/port-kotlin-remove-sp

Conversation

@projedi

Copy link
Copy Markdown
Member

No description provided.

`RemoveRedundantSafepointsPass` was called manually from a compiler
phase. This commits turns it into a proper LLVM pass and calls
it via `LLVMKotlinRunPasses`.

^KT-84060
`RemoveRedundantSafepointsPass` operates on functions, so it can
be safely made into a function pass.

^KT-84060
`RemoveRedundantSafepointsPass` internals were implemented using
LLVM C API for a long time. Convert them to a more convenient
C++ API.

Additionally, make the pass track if it made any changes to avoid
needlessly invalidating analysises.

^KT-84060
@kotlin-safemerge

kotlin-safemerge Bot commented Jun 18, 2026

Copy link
Copy Markdown

@projedi

Copy link
Copy Markdown
Member Author

/dry-run

@KotlinBuild

Build Server (KotlinBuild) commented Jun 18, 2026

Copy link
Copy Markdown

THIS IS A DRY RUN

Quality gate is triggered at https://buildserver.labs.intellij.net/build/977499308 — use this link to get full insight.

Quality gate was triggered with the following revisions:

kotlin
Branch: refs/merge/GITHUB-6301/safe-merge
Commit: 1fa9a8d


Quality gate finished successfully.

@projedi

Alexander Shabalin (projedi) commented Jun 18, 2026

Copy link
Copy Markdown
Member Author

Checked that between the old implementation, the new one and the fallback runLLVMPassesInCompiler=true, the generated bitcode didn't change in both optimized and optimized for small binary modes.

Also checked that the phase took the same time. However, something weird:

DYNAMIC PHASE     461 ms (llvm-remove-sp.ModuleToFunctionPassAdaptor)
DYNAMIC PHASE     455 ms (llvm-remove-sp.ModuleToFunctionPassAdaptor.PassManager<Function>)
DYNAMIC PHASE     437 ms (llvm-remove-sp.ModuleToFunctionPassAdaptor.PassManager<Function>.kotlin::RemoveRedundantSafepointsPass)
DYNAMIC PHASE       0 ms (llvm-remove-sp.ModuleToFunctionPassAdaptor.InnerAnalysisManagerProxy<FunctionAnalysisManager, Module>)
DYNAMIC PHASE    5904 ms (RemoveRedundantSafepoints)

maybe our llvm pass measurement is faulty. EDIT: the phase time included LLVM module dump, skewing the result; remeasured

The phase time improved by ~10%, the fallback version is faster by ~10% on top of that and matches LLVM pass time. So, the difference between llvm pass and the callback comes from the separate LLVMKotlinRunPasses call; which hints, that some compiler phases should be squashed together into a single one, that combines passes in a single call to LLVMKotlinRunPasses (trying to squash all LLVM phases into a single one is probably too limiting, requires some research).

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.

2 participants