SelectionDAG's SimplifySelectOps can take a pathological amount of time #60132
Labels
Comments
hasPredecessorHelper already takes an optional MaxSteps limit that we could make use of |
staticfloat
added a commit
to JuliaLang/llvm-project
that referenced
this issue
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. X-ref: llvm#60132
vchuravy
pushed a commit
to JuliaLang/llvm-project
that referenced
this issue
Apr 16, 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. X-ref: llvm#60132 (cherry picked from commit 2105735)
vchuravy
pushed a commit
to JuliaLang/llvm-project
that referenced
this issue
Apr 16, 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. X-ref: llvm#60132
vchuravy
pushed a commit
to JuliaLang/llvm-project
that referenced
this issue
Apr 30, 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. X-ref: llvm#60132
maleadt
pushed a commit
to JuliaLang/llvm-project
that referenced
this issue
Aug 2, 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. X-ref: llvm#60132
maleadt
pushed a commit
to JuliaLang/llvm-project
that referenced
this issue
Aug 2, 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. X-ref: llvm#60132
vchuravy
pushed a commit
to JuliaLang/llvm-project
that referenced
this issue
Oct 6, 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. X-ref: llvm#60132
giordano
pushed a commit
to JuliaLang/llvm-project
that referenced
this issue
Dec 27, 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. X-ref: llvm#60132
giordano
pushed a commit
to JuliaLang/llvm-project
that referenced
this issue
Mar 8, 2024
`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 (cherry picked from commit 8a2c8f5)
giordano
pushed a commit
to JuliaLang/llvm-project
that referenced
this issue
May 2, 2024
`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 (cherry picked from commit 8a2c8f5)
giordano
pushed a commit
to JuliaLang/llvm-project
that referenced
this issue
Jun 18, 2024
`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 (cherry picked from commit 8a2c8f5)
giordano
pushed a commit
to JuliaLang/llvm-project
that referenced
this issue
Sep 6, 2024
`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 (cherry picked from commit 8a2c8f5) (cherry picked from commit d7563d0)
giordano
pushed a commit
to JuliaLang/llvm-project
that referenced
this issue
Sep 17, 2024
`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 (cherry picked from commit 8a2c8f5) (cherry picked from commit d7563d0)
giordano
pushed a commit
to JuliaLang/llvm-project
that referenced
this issue
Oct 8, 2024
`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 (cherry picked from commit 8a2c8f5) (cherry picked from commit d7563d0)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Consider the attached
.bcfile. This file is quite large (about 4MB uncompressed,about 300k IR statements, all in one function with very large BBs). As such, it is no surprise that
compiling it may take same time. However, on LLVM master the compile time (
llc A2.bc)is excessive (I haven't actually been patient enough to let it finish yet, but
at least three hours).
The compile time improves dramatically if I disable the SimplifySelectOps load reassociation:
With this patch applied, the whole compilation finishes in about 25s, which seems
reasonable to me for this size IR.
I think there are some low-hanging fruits to improve performance slightly, but the
overall problem here is algorithmic. The
SDNode::hasPredecessorHelper(LLD, Visited, Worklist))check that is used to avoidintroducing cycles needs to essentially walk the entire function, which in functions
as large as this is very expensive.
I think there's a couple of options here:
I'm of course also working on making the frontend emit something nicer here and maybe have it split the function into a few parts, but it would be good to fix it in both places if possible.
A2.bc.tar.gz
The text was updated successfully, but these errors were encountered: