-
Notifications
You must be signed in to change notification settings - Fork 148
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
deeply-nested benchmark is troublesome for LLVM #823
Comments
This seems like precisely the reason to not change the benchmark - we don't want user code to hit this. If there's an LLVM bug we should fix that directly. |
Right, bug impacts users right now and should be fixed (see other examples in linked thread that expose it right now). Exposing it in this benchmark is a matter of simplifying the IR enough to change inlining decision in LLVM (while keeping empty and chain in separate codegen unit). It isn't indicative whether problem is present in general or not, so keeping it as is is mostly a source of trouble with little benefits, especially that benchmarks is completely artifical (chaining empty iterators of ZSTs). |
The deeply-nested benchmarks have at various times in the past exposed a performance bug in LLVM. Depending on inlining decisions and unit partitioning the compilation might require a few orders of magnitude more time to complete than usual:
Consider changing the benchmark to avoid the issue (e.g., use a single codegen unit) or removing the benchmark altogether.
The text was updated successfully, but these errors were encountered: