-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Bad LLVM code generation on Aarch64 Darwin #39818
Comments
Alright, through some carefully placed assertions, it looks like this comes from the expansion of a
However, they expand into the adrp+add seen above, so the |
Here's a (bugpoint-reduced) test case that fails on LLVM11, but doesn't fail on master: https://gist.github.com/Keno/a2bb9385fa9b0426df057b9b37652980. I'll bisect LLVM to see if there was an intentional fix of some sort, though I suspect it may just be sensitive to perturbation. |
Bisect result:
Which makes sense, since this selection could only possibly work if the instruction is dead, so a more aggressive dce would remove it. I'll put up an upstream patch in anyway and also put together an LLVM11 patch for us. |
Patch upstream at https://reviews.llvm.org/D97435 even if the web frontend seems broken. |
Includes patches for JuliaLang/julia#39823 JuliaLang/julia#39820 JuliaLang/julia#39818 as well as an issue causing an assertion in debug mode due to address spaces.
Includes patches for JuliaLang/julia#39823 JuliaLang/julia#39820 JuliaLang/julia#39818 as well as an issue causing an assertion in debug mode due to address spaces.
Includes patches for JuliaLang/julia#39823 JuliaLang/julia#39820 JuliaLang/julia#39818 as well as an issue causing an assertion in debug mode due to address spaces.
This constrains the Mov* and similar pseudo instruction to take GPR64common register classes rather than GPR64. GPR64 includs XZR which is invalid here, because this pseudo instructions expands into an adrp/add pair sharing a destination register. XZR is invalid on add and attempting to encode it will instead increment the stack pointer causing crashes (downstream report at [1]). The test case there reproduces on LLVM11, but I do not have a test case that reaches this code path on main, since it is being masked by improved dead code elimination introduced in D91513. Nevertheless, this seems like a good thing to fix in case there are other cases that dead code elimination doesn't clean up (e.g. if `optnone` is used and the optimization is skipped). I think it would be worth auditing uses of GPR64 in pseudo instructions to see if there are any similar issues, but I do not have a high enough view of the backend or knowledge of the Aarch64 architecture to do this quickly. [1] JuliaLang/julia#39818 Reviewed By: t.p.northover Differential Revision: https://reviews.llvm.org/D97435
This constrains the Mov* and similar pseudo instruction to take GPR64common register classes rather than GPR64. GPR64 includs XZR which is invalid here, because this pseudo instructions expands into an adrp/add pair sharing a destination register. XZR is invalid on add and attempting to encode it will instead increment the stack pointer causing crashes (downstream report at [1]). The test case there reproduces on LLVM11, but I do not have a test case that reaches this code path on main, since it is being masked by improved dead code elimination introduced in D91513. Nevertheless, this seems like a good thing to fix in case there are other cases that dead code elimination doesn't clean up (e.g. if `optnone` is used and the optimization is skipped). I think it would be worth auditing uses of GPR64 in pseudo instructions to see if there are any similar issues, but I do not have a high enough view of the backend or knowledge of the Aarch64 architecture to do this quickly. [1] JuliaLang/julia#39818 Reviewed By: t.p.northover Differential Revision: https://reviews.llvm.org/D97435
This constrains the Mov* and similar pseudo instruction to take GPR64common register classes rather than GPR64. GPR64 includs XZR which is invalid here, because this pseudo instructions expands into an adrp/add pair sharing a destination register. XZR is invalid on add and attempting to encode it will instead increment the stack pointer causing crashes (downstream report at [1]). The test case there reproduces on LLVM11, but I do not have a test case that reaches this code path on main, since it is being masked by improved dead code elimination introduced in D91513. Nevertheless, this seems like a good thing to fix in case there are other cases that dead code elimination doesn't clean up (e.g. if `optnone` is used and the optimization is skipped). I think it would be worth auditing uses of GPR64 in pseudo instructions to see if there are any similar issues, but I do not have a high enough view of the backend or knowledge of the Aarch64 architecture to do this quickly. [1] JuliaLang/julia#39818 Reviewed By: t.p.northover Differential Revision: https://reviews.llvm.org/D97435
This constrains the Mov* and similar pseudo instruction to take GPR64common register classes rather than GPR64. GPR64 includs XZR which is invalid here, because this pseudo instructions expands into an adrp/add pair sharing a destination register. XZR is invalid on add and attempting to encode it will instead increment the stack pointer causing crashes (downstream report at [1]). The test case there reproduces on LLVM11, but I do not have a test case that reaches this code path on main, since it is being masked by improved dead code elimination introduced in D91513. Nevertheless, this seems like a good thing to fix in case there are other cases that dead code elimination doesn't clean up (e.g. if `optnone` is used and the optimization is skipped). I think it would be worth auditing uses of GPR64 in pseudo instructions to see if there are any similar issues, but I do not have a high enough view of the backend or knowledge of the Aarch64 architecture to do this quickly. [1] JuliaLang/julia#39818 Reviewed By: t.p.northover Differential Revision: https://reviews.llvm.org/D97435 (cherry picked from commit 089b115)
This constrains the Mov* and similar pseudo instruction to take GPR64common register classes rather than GPR64. GPR64 includs XZR which is invalid here, because this pseudo instructions expands into an adrp/add pair sharing a destination register. XZR is invalid on add and attempting to encode it will instead increment the stack pointer causing crashes (downstream report at [1]). The test case there reproduces on LLVM11, but I do not have a test case that reaches this code path on main, since it is being masked by improved dead code elimination introduced in D91513. Nevertheless, this seems like a good thing to fix in case there are other cases that dead code elimination doesn't clean up (e.g. if `optnone` is used and the optimization is skipped). I think it would be worth auditing uses of GPR64 in pseudo instructions to see if there are any similar issues, but I do not have a high enough view of the backend or knowledge of the Aarch64 architecture to do this quickly. [1] JuliaLang/julia#39818 Reviewed By: t.p.northover Differential Revision: https://reviews.llvm.org/D97435 (cherry picked from commit e20f69f)
This constrains the Mov* and similar pseudo instruction to take GPR64common register classes rather than GPR64. GPR64 includs XZR which is invalid here, because this pseudo instructions expands into an adrp/add pair sharing a destination register. XZR is invalid on add and attempting to encode it will instead increment the stack pointer causing crashes (downstream report at [1]). The test case there reproduces on LLVM11, but I do not have a test case that reaches this code path on main, since it is being masked by improved dead code elimination introduced in D91513. Nevertheless, this seems like a good thing to fix in case there are other cases that dead code elimination doesn't clean up (e.g. if `optnone` is used and the optimization is skipped). I think it would be worth auditing uses of GPR64 in pseudo instructions to see if there are any similar issues, but I do not have a high enough view of the backend or knowledge of the Aarch64 architecture to do this quickly. [1] JuliaLang/julia#39818 Reviewed By: t.p.northover Differential Revision: https://reviews.llvm.org/D97435 (cherry picked from commit e20f69f)
This constrains the Mov* and similar pseudo instruction to take GPR64common register classes rather than GPR64. GPR64 includs XZR which is invalid here, because this pseudo instructions expands into an adrp/add pair sharing a destination register. XZR is invalid on add and attempting to encode it will instead increment the stack pointer causing crashes (downstream report at [1]). The test case there reproduces on LLVM11, but I do not have a test case that reaches this code path on main, since it is being masked by improved dead code elimination introduced in D91513. Nevertheless, this seems like a good thing to fix in case there are other cases that dead code elimination doesn't clean up (e.g. if `optnone` is used and the optimization is skipped). I think it would be worth auditing uses of GPR64 in pseudo instructions to see if there are any similar issues, but I do not have a high enough view of the backend or knowledge of the Aarch64 architecture to do this quickly. [1] JuliaLang/julia#39818 Reviewed By: t.p.northover Differential Revision: https://reviews.llvm.org/D97435 (cherry picked from commit e20f69f)
This constrains the Mov* and similar pseudo instruction to take GPR64common register classes rather than GPR64. GPR64 includs XZR which is invalid here, because this pseudo instructions expands into an adrp/add pair sharing a destination register. XZR is invalid on add and attempting to encode it will instead increment the stack pointer causing crashes (downstream report at [1]). The test case there reproduces on LLVM11, but I do not have a test case that reaches this code path on main, since it is being masked by improved dead code elimination introduced in D91513. Nevertheless, this seems like a good thing to fix in case there are other cases that dead code elimination doesn't clean up (e.g. if `optnone` is used and the optimization is skipped). I think it would be worth auditing uses of GPR64 in pseudo instructions to see if there are any similar issues, but I do not have a high enough view of the backend or knowledge of the Aarch64 architecture to do this quickly. [1] JuliaLang/julia#39818 Reviewed By: t.p.northover Differential Revision: https://reviews.llvm.org/D97435 (cherry picked from commit e20f69f)
This constrains the Mov* and similar pseudo instruction to take GPR64common register classes rather than GPR64. GPR64 includs XZR which is invalid here, because this pseudo instructions expands into an adrp/add pair sharing a destination register. XZR is invalid on add and attempting to encode it will instead increment the stack pointer causing crashes (downstream report at [1]). The test case there reproduces on LLVM11, but I do not have a test case that reaches this code path on main, since it is being masked by improved dead code elimination introduced in D91513. Nevertheless, this seems like a good thing to fix in case there are other cases that dead code elimination doesn't clean up (e.g. if `optnone` is used and the optimization is skipped). I think it would be worth auditing uses of GPR64 in pseudo instructions to see if there are any similar issues, but I do not have a high enough view of the backend or knowledge of the Aarch64 architecture to do this quickly. [1] JuliaLang/julia#39818 Reviewed By: t.p.northover Differential Revision: https://reviews.llvm.org/D97435
LLVM generates the following code on AArch64 darwin under
make debug
:The last statement here is invalid and actually encodes
add sp, sp, __MergedGlobals.1@PAGEOFF
, which corrupts the stack.The text was updated successfully, but these errors were encountered: