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

Disable pathologically expensive SimplifySelectOps optimization #14

Merged
merged 1 commit into from
Apr 16, 2023

Conversation

staticfloat
Copy link
Sponsor Member

@staticfloat staticfloat commented Mar 28, 2023

SimplifySelectOps is a late optimization in LLVM that attempts to translate select(C, load(A), load(B)) into load(select(C, A, B)). However, in order for it to do this optimization, it needs to check that C does not depend on the result of load(A) or load(B). Unfortunately (unlikely Julia and LLVM at the IR level), LLVM does not have a topological order of statements computed at this stage of the compiler, so LLVM needs to iterate through all statements in the function in order to perform this legality check. For large functions, this is extremely expensive, accounting for the majority of all compilation time for such functions. On the other hand, the optimization itself is minor, allowing at most the elision of one additional load (and doesn't fire particularly often, because the middle end can perform similar optimizations). Until there is a proper solution in LLVM, simply disable this optimizations, making LLVM several orders of magnitude faster on real world benchmarks.

`SimplifySelectOps` is a late optimization in LLVM that attempts to
translate `select(C, load(A), load(B))` into `load(select(C, A, B))`.
However, in order for it to do this optimization, it needs to check that
`C` does not depend on the result of `load(A)` or `load(B)`.
Unfortunately (unlikely Julia and LLVM at the IR level), LLVM does not
have a topological order of statements computed at this stage of the
compiler, so LLVM needs to iterate through all statements in the
function in order to perform this legality check. For large functions,
this is extremely expensive, accounting for the majority of all
compilation time for such functions. On the other hand, the optimization
itself is minor, allowing at most the elision of one additional load
(and doesn't fire particularly often, because the middle end can perform
similar optimizations). Until there is a proper solution in LLVM, simply
disable this optimizations, making LLVM several orders of magnitude
faster on real world benchmarks.

X-ref: llvm#60132
@vchuravy
Copy link
Sponsor Member

Merged into 14.x as 5c82f53

@vchuravy vchuravy deleted the sf/llvm_sso_patch branch April 16, 2023 14:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants