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

[DAG] Add legalization handling for ABDS/ABDU #92576

Merged
merged 4 commits into from
Aug 6, 2024
Merged

Conversation

RKSimon
Copy link
Collaborator

@RKSimon RKSimon commented May 17, 2024

Always match ABD patterns pre-legalization, and use TargetLowering::expandABD to expand again during legalization.

abdu(lhs, rhs) -> sub(xor(sub(lhs, rhs), usub_overflowlhs, rhs)), usub_overflow(lhs, rhs))
Alive2: https://alive2.llvm.org/ce/z/dVdMyv

Copy link

github-actions bot commented May 17, 2024

⚠️ C/C++ code formatter, clang-format found issues in your code. ⚠️

You can test this locally with the following command:
git-clang-format --diff 37e75cdf9f432940cfbdcab3a3d8d93eba15bca4 ea442ed3ce6720b07ae973001c499fc37eb9c212 --extensions h,cpp -- llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp llvm/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.h llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp
View the diff from clang-format here.
diff --git a/llvm/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp b/llvm/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp
index fefb0844f1..0b9ca13c71 100644
--- a/llvm/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp
+++ b/llvm/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp
@@ -2796,7 +2796,9 @@ void DAGTypeLegalizer::ExpandIntegerResult(SDNode *N, unsigned ResNo) {
   case ISD::Constant:    ExpandIntRes_Constant(N, Lo, Hi); break;
   case ISD::ABS:         ExpandIntRes_ABS(N, Lo, Hi); break;
   case ISD::ABDS:
-  case ISD::ABDU:        ExpandIntRes_ABD(N, Lo, Hi); break;
+  case ISD::ABDU:
+    ExpandIntRes_ABD(N, Lo, Hi);
+    break;
   case ISD::CTLZ_ZERO_UNDEF:
   case ISD::CTLZ:        ExpandIntRes_CTLZ(N, Lo, Hi); break;
   case ISD::CTPOP:       ExpandIntRes_CTPOP(N, Lo, Hi); break;
diff --git a/llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.h b/llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.h
index 3a49a8ff10..aaaf4cfb7e 100644
--- a/llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.h
+++ b/llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.h
@@ -448,7 +448,7 @@ private:
   void ExpandIntRes_AssertZext        (SDNode *N, SDValue &Lo, SDValue &Hi);
   void ExpandIntRes_Constant          (SDNode *N, SDValue &Lo, SDValue &Hi);
   void ExpandIntRes_ABS               (SDNode *N, SDValue &Lo, SDValue &Hi);
-  void ExpandIntRes_ABD               (SDNode *N, SDValue &Lo, SDValue &Hi);
+  void ExpandIntRes_ABD(SDNode *N, SDValue &Lo, SDValue &Hi);
   void ExpandIntRes_CTLZ              (SDNode *N, SDValue &Lo, SDValue &Hi);
   void ExpandIntRes_CTPOP             (SDNode *N, SDValue &Lo, SDValue &Hi);
   void ExpandIntRes_CTTZ              (SDNode *N, SDValue &Lo, SDValue &Hi);

RKSimon added a commit that referenced this pull request May 19, 2024
No need for this to be vector specific, and its more likely that scalar cases will appear after #92576
@RKSimon RKSimon force-pushed the legal-abd branch 2 times, most recently from a8f211a to 7ff766e Compare May 20, 2024 13:39
RKSimon added a commit to RKSimon/llvm-project that referenced this pull request May 20, 2024
…mparison result cases

If the comparison results are allbits masks, we can expand as "abd(lhs, rhs) -> sub(cmpgt(lhs, rhs), xor(sub(lhs, rhs), cmpgt(lhs, rhs)))", replacing a sub+sub+select pattern with the simpler sub+xor+sub pattern.

This allows us to remove a lot of X86 specific legalization code, and will be useful in future generic expansion for the legalization work in llvm#92576

Alive2: https://alive2.llvm.org/ce/z/sj863C
RKSimon added a commit to RKSimon/llvm-project that referenced this pull request May 21, 2024
…mparison result cases

If the comparison results are allbits masks, we can expand as "abd(lhs, rhs) -> sub(cmpgt(lhs, rhs), xor(sub(lhs, rhs), cmpgt(lhs, rhs)))", replacing a sub+sub+select pattern with the simpler sub+xor+sub pattern.

This allows us to remove a lot of X86 specific legalization code, and will be useful in future generic expansion for the legalization work in llvm#92576

Alive2: https://alive2.llvm.org/ce/z/sj863C
RKSimon added a commit to RKSimon/llvm-project that referenced this pull request May 23, 2024
…mparison result cases

If the comparison results are allbits masks, we can expand as "abd(lhs, rhs) -> sub(cmpgt(lhs, rhs), xor(sub(lhs, rhs), cmpgt(lhs, rhs)))", replacing a sub+sub+select pattern with the simpler sub+xor+sub pattern.

This allows us to remove a lot of X86 specific legalization code, and will be useful in future generic expansion for the legalization work in llvm#92576

Alive2: https://alive2.llvm.org/ce/z/sj863C
RKSimon added a commit to RKSimon/llvm-project that referenced this pull request May 23, 2024
…mparison result cases

If the comparison results are allbits masks, we can expand as "abd(lhs, rhs) -> sub(cmpgt(lhs, rhs), xor(sub(lhs, rhs), cmpgt(lhs, rhs)))", replacing a sub+sub+select pattern with the simpler sub+xor+sub pattern.

This allows us to remove a lot of X86 specific legalization code, and will be useful in future generic expansion for the legalization work in llvm#92576

Alive2: https://alive2.llvm.org/ce/z/sj863C
RKSimon added a commit that referenced this pull request May 23, 2024
…mparison result cases (#92780)

If the comparison results are allbits masks, we can expand as `abd(lhs, rhs) -> sub(cmpgt(lhs, rhs), xor(sub(lhs, rhs), cmpgt(lhs, rhs)))`, replacing a sub+sub+select pattern with the simpler sub+xor+sub pattern.

This allows us to remove a lot of X86 specific legalization code, and will be useful in future generic expansion for the legalization work in #92576

Alive2: https://alive2.llvm.org/ce/z/sj863C
@RKSimon RKSimon force-pushed the legal-abd branch 2 times, most recently from 06e295a to 707feb8 Compare May 23, 2024 10:58
RKSimon added a commit that referenced this pull request May 23, 2024
Improve test checks for better codegen review of #92576
@RKSimon RKSimon force-pushed the legal-abd branch 3 times, most recently from d6b7540 to ba56c87 Compare June 4, 2024 12:23
@RKSimon RKSimon force-pushed the legal-abd branch 2 times, most recently from b7b3e2d to 074aac2 Compare June 5, 2024 11:46
@ZequanWu
Copy link
Contributor

ZequanWu commented Aug 6, 2024

This cause clang to crash:

1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module 'rdopt-2bbb04.txt'.
4.      Running pass 'ARM Instruction Selection' on function '@vp8_rd_pick_inter_mode'
 #0 0x000055c5b52cdd88 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/local/google/home/zequanwu/workspace/llvm-project/build/cmake/bin/clang-19+0x7daed88)
 #1 0x000055c5b52cb83e llvm::sys::RunSignalHandlers() (/usr/local/google/home/zequanwu/workspace/llvm-project/build/cmake/bin/clang-19+0x7dac83e)
 #2 0x000055c5b52ce438 SignalHandler(int) Signals.cpp:0:0
 #3 0x00007f8567e591a0 (/lib/x86_64-linux-gnu/libc.so.6+0x3d1a0)
 #4 0x00007f8567ea70ec __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
 #5 0x00007f8567e59102 gsignal ./signal/../sysdeps/posix/raise.c:27:6
 #6 0x00007f8567e424f2 abort ./stdlib/abort.c:81:7
 #7 0x00007f8567e42415 _nl_load_domain ./intl/loadmsgcat.c:1177:9
 #8 0x00007f8567e51d32 (/lib/x86_64-linux-gnu/libc.so.6+0x35d32)
 #9 0x000055c5b641032c (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*) LegalizeDAG.cpp:0:0
#10 0x000055c5b6410026 llvm::SelectionDAG::Legalize() (/usr/local/google/home/zequanwu/workspace/llvm-project/build/cmake/bin/clang-19+0x8ef1026)
#11 0x000055c5b64fdda8 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/usr/local/google/home/zequanwu/workspace/llvm-project/build/cmake/bin/clang-19+0x8fdeda8)
#12 0x000055c5b64fc282 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/usr/local/google/home/zequanwu/workspace/llvm-project/build/cmake/bin/clang-19+0x8fdd282)
#13 0x000055c5b64f9351 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/usr/local/google/home/zequanwu/workspace/llvm-project/build/cmake/bin/clang-19+0x8fda351)
#14 0x000055c5b3517121 (anonymous namespace)::ARMDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) ARMISelDAGToDAG.cpp:0:0
#15 0x000055c5b64f6ce6 llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) (/usr/local/google/home/zequanwu/workspace/llvm-project/build/cmake/bin/clang-19+0x8fd7ce6)
#16 0x000055c5b478bb27 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/usr/local/google/home/zequanwu/workspace/llvm-project/build/cmake/bin/clang-19+0x726cb27)
#17 0x000055c5b4cc9c82 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/local/google/home/zequanwu/workspace/llvm-project/build/cmake/bin/clang-19+0x77aac82)
#18 0x000055c5b4cd24f2 llvm::FPPassManager::runOnModule(llvm::Module&) (/usr/local/google/home/zequanwu/workspace/llvm-project/build/cmake/bin/clang-19+0x77b34f2)
#19 0x000055c5b4cca826 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/local/google/home/zequanwu/workspace/llvm-project/build/cmake/bin/clang-19+0x77ab826)
#20 0x000055c5b5aa0944 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem>, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream>>, clang::BackendConsumer*) (/usr/local/google/home/zequanwu/workspace/llvm-project/build/cmake/bin/clang-19+0x8581944)
#21 0x000055c5b5ac4610 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/usr/local/google/home/zequanwu/workspace/llvm-project/build/cmake/bin/clang-19+0x85a5610)
#22 0x000055c5b7710ec9 clang::ParseAST(clang::Sema&, bool, bool) (/usr/local/google/home/zequanwu/workspace/llvm-project/build/cmake/bin/clang-19+0xa1f1ec9)
#23 0x000055c5b5f1879f clang::FrontendAction::Execute() (/usr/local/google/home/zequanwu/workspace/llvm-project/build/cmake/bin/clang-19+0x89f979f)
#24 0x000055c5b5e8518d clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/local/google/home/zequanwu/workspace/llvm-project/build/cmake/bin/clang-19+0x896618d)
#25 0x000055c5b5ff1259 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/local/google/home/zequanwu/workspace/llvm-project/build/cmake/bin/clang-19+0x8ad2259)
#26 0x000055c5b2b564ba cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/usr/local/google/home/zequanwu/workspace/llvm-project/build/cmake/bin/clang-19+0x56374ba)
#27 0x000055c5b2b525b9 ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&, llvm::ToolContext const&) driver.cpp:0:0
#28 0x000055c5b2b5141a clang_main(int, char**, llvm::ToolContext const&) (/usr/local/google/home/zequanwu/workspace/llvm-project/build/cmake/bin/clang-19+0x563241a)
#29 0x000055c5b2b626b7 main (/usr/local/google/home/zequanwu/workspace/llvm-project/build/cmake/bin/clang-19+0x56436b7)
#30 0x00007f8567e43b8a __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3
#31 0x00007f8567e43c45 call_init ./csu/../csu/libc-start.c:128:20
#32 0x00007f8567e43c45 __libc_start_main ./csu/../csu/libc-start.c:347:5
#33 0x000055c5b2b4ff21 _start (/usr/local/google/home/zequanwu/workspace/llvm-project/build/cmake/bin/clang-19+0x5630f21)

Repro command:

clang -cc1 -triple thumbv7-unknown-linux-android26 -emit-obj -disable-free -clear-ast-before-backend -main-file-name rdopt.c -mrelocation-model pic -pic-level 2 -fhalf-no-semantic-interposition -fmerge-all-constants -fno-delete-null-pointer-checks -mframe-pointer=none -relaxed-aliasing -ffp-contract=off -fno-rounding-math -mconstructor-aliases -funwind-tables=1 -target-cpu generic -target-feature +soft-float-abi -target-feature +vfp2 -target-feature +vfp2sp -target-feature +vfp3 -target-feature +vfp3d16 -target-feature +vfp3d16sp -target-feature +vfp3sp -target-feature -fp16 -target-feature -vfp4 -target-feature -vfp4d16 -target-feature -vfp4d16sp -target-feature -vfp4sp -target-feature -fp-armv8 -target-feature -fp-armv8d16 -target-feature -fp-armv8d16sp -target-feature -fp-armv8sp -target-feature -fullfp16 -target-feature +fp64 -target-feature +d32 -target-feature +neon -target-feature -sha2 -target-feature -aes -target-feature -fp16fml -target-abi aapcs-linux -mfloat-abi soft -debug-info-kind=constructor -dwarf-version=4 -debugger-tuning=gdb -mllvm -generate-arange-section -fdebug-compilation-dir=. -mllvm -crash-diagnostics-dir=../../tools/clang/crashreports -ffunction-sections -fdata-sections -fno-unique-section-names -fcoverage-compilation-dir=. -D DCHECK_ALWAYS_ON=1 -D _GNU_SOURCE -D _LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_EXTENSIVE -D ANDROID -D __ANDROID_UNAVAILABLE_SYMBOLS_ARE_WEAK__ -D HAVE_SYS_UIO_H -D ANDROID_NDK_VERSION_ROLL=r27_1 -D CR_CLANG_REVISION=\"llvmorg-20-init-1480-gb1234ddb-0\" -D COMPONENT_BUILD -D CR_LIBCXX_REVISION=6dd205ff6019b359f31405faf7b664090ce790fe -D TEMP_REBUILD_HACK -D _DEBUG -D DYNAMIC_ANNOTATIONS_ENABLED=1 -D CHROMIUM -D "VPX_MAX_ALLOCABLE_MEMORY=((1ULL << 31) - (1 << 21))" -D __DATE__= -D __TIME__= -D __TIMESTAMP__= -Oz -Wno-builtin-macro-redefined -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -Wall -Wno-unused-variable -Wno-c++11-narrowing -Wno-unused-but-set-variable -Wno-misleading-indentation -Wunguarded-availability -Wno-missing-field-initializers -Wno-unused-parameter -Wno-psabi -Wloop-analysis -Wno-unneeded-internal-declaration -Wno-cast-function-type -Wno-deprecated-this-capture -Wno-invalid-offsetof -Wno-vla-extension -Wno-thread-safety-reference-return -Werror -Wno-conversion -Wno-parentheses-equality -Wno-unused-function -std=c11 -ferror-limit 19 -fvisibility=hidden -femulated-tls -stack-protector 1 -ftrivial-auto-var-init=pattern -fno-signed-char -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fno-sized-deallocation -Qn -fcolor-diagnostics -vectorize-slp -fuse-ctor-homing -D__GCC_HAVE_DWARF2_CFI_ASM=1 -x c rdopt-2bbb04.txt

rdopt-2bbb04.txt

@RKSimon
Copy link
Collaborator Author

RKSimon commented Aug 7, 2024

Thanks @ZequanWu I have the repro and am reducing it now

banach-space pushed a commit to banach-space/llvm-project that referenced this pull request Aug 7, 2024
…100810

Extend test coverage for llvm#92576 - copied from existing x86 tests
banach-space pushed a commit to banach-space/llvm-project that referenced this pull request Aug 7, 2024
This fixes a problem if abd nodes are generated more readily (llvm#92576).
The folding of abd nodes into abdl needs to check that the inputs are
the correct form of vector. The added test requires vector legalization
to occur in order to hit the combine at the wrong time.
banach-space pushed a commit to banach-space/llvm-project that referenced this pull request Aug 7, 2024
Always match ABD patterns pre-legalization, and use TargetLowering::expandABD to expand again during legalization.

abdu(lhs, rhs) -> sub(xor(sub(lhs, rhs), usub_overflow(lhs, rhs)), usub_overflow(lhs, rhs))
Alive2: https://alive2.llvm.org/ce/z/dVdMyv
@bgra8
Copy link
Contributor

bgra8 commented Aug 7, 2024

@RKSimon this patch enters an infinite loop while compiling a CC file that only takes 2.5s to compile with the previous version.

Here's 3 stack samples at 3 different moments:

T1:

#0  0x000055555c5e96d5 in (anonymous namespace)::SelectionDAGLegalize::ExpandNode(llvm::SDNode*) ()
#1  0x000055555c5e45d2 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*) ()
#2  0x000055555c5e3c07 in llvm::SelectionDAG::Legalize() ()
#3  0x000055555c6a0bdc in llvm::SelectionDAGISel::CodeGenAndEmitDAG() ()
#4  0x000055555c69f744 in llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) ()
#5  0x000055555c69e0c8 in llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) ()
#6  0x000055555c69c9e1 in llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) ()
#7  0x000055555c37924f in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) ()
#8  0x000055555d6d88f2 in llvm::FPPassManager::runOnFunction(llvm::Function&) ()
#9  0x000055555d6df424 in llvm::FPPassManager::runOnModule(llvm::Module&) ()
#10 0x000055555d6d9165 in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
#11 0x0000555558ad3a64 in clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem>, std::__u::unique_ptr<llvm::raw_pwrite_stream, std::__u::default_delete<llvm::raw_pwrite_stream> >, clang::BackendConsumer*) ()
#12 0x00005555587a44f7 in clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) ()
#13 0x0000555559602cf9 in clang::ParseAST(clang::Sema&, bool, bool) ()
#14 0x000055555936925a in clang::FrontendAction::Execute() ()
#15 0x00005555592e06a4 in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) ()
#16 0x000055555846b35f in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) ()
#17 0x00005555584606b6 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) ()
#18 0x000055555845d3e6 in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&, llvm::ToolContext const&) ()
#19 0x000055555845c1cb in clang_main(int, char**, llvm::ToolContext const&) ()
#20 0x000055555845ae34 in main ()

T2:

#0  0x000055555c604f04 in llvm::SelectionDAG::DeleteNode(llvm::SDNode*) ()
#1  0x000055555c5e3baf in llvm::SelectionDAG::Legalize() ()
#2  0x000055555c6a0bdc in llvm::SelectionDAGISel::CodeGenAndEmitDAG() ()
#3  0x000055555c69f744 in llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) ()
#4  0x000055555c69e0c8 in llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) ()
#5  0x000055555c69c9e1 in llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) ()
#6  0x000055555c37924f in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) ()
#7  0x000055555d6d88f2 in llvm::FPPassManager::runOnFunction(llvm::Function&) ()
#8  0x000055555d6df424 in llvm::FPPassManager::runOnModule(llvm::Module&) ()
#9  0x000055555d6d9165 in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
#10 0x0000555558ad3a64 in clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem>, std::__u::unique_ptr<llvm::raw_pwrite_stream, std::__u::default_delete<llvm::raw_pwrite_stream> >, clang::BackendConsumer*) ()
#11 0x00005555587a44f7 in clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) ()
#12 0x0000555559602cf9 in clang::ParseAST(clang::Sema&, bool, bool) ()
#13 0x000055555936925a in clang::FrontendAction::Execute() ()
#14 0x00005555592e06a4 in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) ()
#15 0x000055555846b35f in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) ()
#16 0x00005555584606b6 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) ()
#17 0x000055555845d3e6 in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&, llvm::ToolContext const&) ()
#18 0x000055555845c1cb in clang_main(int, char**, llvm::ToolContext const&) ()
#19 0x000055555845ae34 in main ()

T3:

#0  0x000055555d8d018b in llvm::SmallPtrSetImplBase::insert_imp_big(void const*) ()
#1  0x000055555c5e3bf3 in llvm::SelectionDAG::Legalize() ()
#2  0x000055555c6a0bdc in llvm::SelectionDAGISel::CodeGenAndEmitDAG() ()
#3  0x000055555c69f744 in llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) ()
#4  0x000055555c69e0c8 in llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) ()
#5  0x000055555c69c9e1 in llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) ()
#6  0x000055555c37924f in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) ()
#7  0x000055555d6d88f2 in llvm::FPPassManager::runOnFunction(llvm::Function&) ()
#8  0x000055555d6df424 in llvm::FPPassManager::runOnModule(llvm::Module&) ()
#9  0x000055555d6d9165 in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
#10 0x0000555558ad3a64 in clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem>, std::__u::unique_ptr<llvm::raw_pwrite_stream, std::__u::default_delete<llvm::raw_pwrite_stream> >, clang::BackendConsumer*) ()
#11 0x00005555587a44f7 in clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) ()
#12 0x0000555559602cf9 in clang::ParseAST(clang::Sema&, bool, bool) ()
#13 0x000055555936925a in clang::FrontendAction::Execute() ()
#14 0x00005555592e06a4 in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) ()
#15 0x000055555846b35f in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) ()
#16 0x00005555584606b6 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) ()
#17 0x000055555845d3e6 in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&, llvm::ToolContext const&) ()
#18 0x000055555845c1cb in clang_main(int, char**, llvm::ToolContext const&) ()
#19 0x000055555845ae34 in main ()

The compilation never finishes (waited more than 15min).

I see you're also investigating a crash. Can you please revert while we work for a reproducer?

@RKSimon
Copy link
Collaborator Author

RKSimon commented Aug 7, 2024

OK - I'll revert shortly - please can you post any more repros that you can.

RKSimon added a commit that referenced this pull request Aug 7, 2024
Reverting #92576 while we identify a reported regression
@bgra8
Copy link
Contributor

bgra8 commented Aug 7, 2024

I started a reduction. I'll post the reproducer soonish.

@RKSimon
Copy link
Collaborator Author

RKSimon commented Aug 7, 2024

@bgra8 I have a fix for the original issue from @ZequanWu - I'm just waiting on a repro from you before I can recommit

@nathanchance
Copy link
Member

@RKSimon I noticed an assertion failure when building the Linux kernel with -fsanitize=thread after this change. I am not sure if it is the same as the other issues mentioned but here is a C reproducer:

enum {
  false,
  IQK_S1_RX_X,
  IQK_S1_RX_Y,
  IQK_S0_TX_X,
  IQK_S0_TX_Y,
  IQK_S0_RX_X,
  IQK_NR
} iqkxy_to_s32___trans_tmp_2;
int __rtw8723x_iqk_similarity_cmp_i, __rtw8723x_iqk_similarity_cmp_diff,
    __rtw8723x_iqk_similarity_cmp___trans_tmp_2,
    __rtw8723x_iqk_similarity_cmp_candidate_0,
    __rtw8723x_iqk_similarity_cmp_tmp1, __rtw8723x_iqk_similarity_cmp_tmp2,
    __rtw8723x_iqk_similarity_cmp_val;
_Bool __rtw8723x_iqk_similarity_cmp(int result[][IQK_NR]) {
  int bitmap = 0;
  for (__rtw8723x_iqk_similarity_cmp_i = 0;
       __rtw8723x_iqk_similarity_cmp_i < IQK_NR;
       __rtw8723x_iqk_similarity_cmp_i++) {
    int index = 9;
    char shift = index;
    iqkxy_to_s32___trans_tmp_2 =
        result[1][__rtw8723x_iqk_similarity_cmp_i] << shift >> shift;
    __rtw8723x_iqk_similarity_cmp_tmp1 = iqkxy_to_s32___trans_tmp_2;
    __rtw8723x_iqk_similarity_cmp_val =
        result[2][__rtw8723x_iqk_similarity_cmp_i];
    iqkxy_to_s32___trans_tmp_2 =
        __rtw8723x_iqk_similarity_cmp_val << shift >> shift;
    __rtw8723x_iqk_similarity_cmp___trans_tmp_2 =
        __rtw8723x_iqk_similarity_cmp_tmp2 = iqkxy_to_s32___trans_tmp_2;
    __rtw8723x_iqk_similarity_cmp_diff = __builtin_choose_expr(
        __builtin_types_compatible_p(typeof(__rtw8723x_iqk_similarity_cmp_tmp2),
                                     long),
        0,
        __builtin_choose_expr(
            __builtin_types_compatible_p(
                typeof(__rtw8723x_iqk_similarity_cmp_tmp2), long),
            0,
            __builtin_choose_expr(
                __builtin_types_compatible_p(
                    typeof(__rtw8723x_iqk_similarity_cmp_tmp2), int),
                ({
                  int __x = __rtw8723x_iqk_similarity_cmp_tmp1 -
                            __rtw8723x_iqk_similarity_cmp_tmp2;
                  __x < 0 ? -__x : __x;
                }),
                __builtin_choose_expr(
                    __builtin_types_compatible_p(
                        typeof(__rtw8723x_iqk_similarity_cmp_tmp2), short),
                    0,
                    __builtin_choose_expr(
                        __builtin_types_compatible_p(
                            typeof(__rtw8723x_iqk_similarity_cmp_tmp2), char),
                        0,
                        __builtin_choose_expr(
                            __builtin_types_compatible_p(
                                typeof(__rtw8723x_iqk_similarity_cmp_tmp2),
                                char),
                            0, 0))))));
    if (__rtw8723x_iqk_similarity_cmp_diff)
      continue;
    if ((__rtw8723x_iqk_similarity_cmp_i == IQK_S1_RX_X ||
         __rtw8723x_iqk_similarity_cmp_i == IQK_S0_RX_X) &&
        bitmap)
      if (result[1][1])
        __rtw8723x_iqk_similarity_cmp_candidate_0 = 2;
    bitmap |= __rtw8723x_iqk_similarity_cmp_i;
  }
  return false;
}
$ clang --target=aarch64-linux-gnu -O2 -fsanitize=thread -c -o /dev/null rtw8723x.i
clang: /home/nathan/tmp/cvise.NoOV35mHWo/src/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:974: void (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(SDNode *): Assertion `(TLI.getTypeAction(*DAG.getContext(), Op.getValueType()) == TargetLowering::TypeLegal || Op.getOpcode() == ISD::TargetConstant || Op.getOpcode() == ISD::Register) && "Unexpected illegal type!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.	Program arguments: clang --target=aarch64-linux-gnu -O2 -fsanitize=thread -c -o /dev/null rtw8723x.i
1.	<eof> parser at end of file
2.	Code generation
3.	Running pass 'Function Pass Manager' on module 'rtw8723x.i'.
4.	Running pass 'AArch64 Instruction Selection' on function '@__rtw8723x_iqk_similarity_cmp'
 #0 0x000055e018b61416 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x565f416)
 #1 0x000055e018b5eede llvm::sys::RunSignalHandlers() (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x565cede)
 #2 0x000055e018ae103d CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
 #3 0x00007f1b2d9091d0 (/usr/lib/libc.so.6+0x3d1d0)
 #4 0x00007f1b2d9623f4 (/usr/lib/libc.so.6+0x963f4)
 #5 0x00007f1b2d909120 raise (/usr/lib/libc.so.6+0x3d120)
 #6 0x00007f1b2d8f04c3 abort (/usr/lib/libc.so.6+0x244c3)
 #7 0x00007f1b2d8f03df (/usr/lib/libc.so.6+0x243df)
 #8 0x00007f1b2d901177 (/usr/lib/libc.so.6+0x35177)
 #9 0x000055e019d7039c (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*) LegalizeDAG.cpp:0:0
#10 0x000055e019d70058 llvm::SelectionDAG::Legalize() (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x686e058)
#11 0x000055e019e639a7 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x69619a7)
#12 0x000055e019e616c7 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x695f6c7)
#13 0x000055e019e5ee41 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x695ce41)
#14 0x000055e019e5c7c6 llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x695a7c6)
#15 0x000055e0180d2452 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x4bd0452)
#16 0x000055e018658cc8 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x5156cc8)
#17 0x000055e018661682 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x515f682)
#18 0x000055e0186597f2 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x51577f2)
#19 0x000055e0193a0760 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem>, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream>>, clang::BackendConsumer*) (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x5e9e760)
#20 0x000055e0193c79b7 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x5ec59b7)
#21 0x000055e01a85a799 clang::ParseAST(clang::Sema&, bool, bool) (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x7358799)
#22 0x000055e01985e67d clang::FrontendAction::Execute() (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x635c67d)
#23 0x000055e0197c261d clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x62c061d)
#24 0x000055e01993b67c clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x643967c)
#25 0x000055e016bb5095 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x36b3095)
#26 0x000055e016bb16dd ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&, llvm::ToolContext const&) driver.cpp:0:0
#27 0x000055e0195e6bd9 void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const::$_0>(long) Job.cpp:0:0
#28 0x000055e018ae0d76 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x55ded76)
#29 0x000055e0195e6273 clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x60e4273)
#30 0x000055e01959dea7 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x609bea7)
#31 0x000055e01959e407 clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&, bool) const (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x609c407)
#32 0x000055e0195c0b39 clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&) (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x60beb39)
#33 0x000055e016bb0b7d clang_main(int, char**, llvm::ToolContext const&) (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x36aeb7d)
#34 0x000055e016bc24f6 main (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x36c04f6)
#35 0x00007f1b2d8f1e08 (/usr/lib/libc.so.6+0x25e08)
#36 0x00007f1b2d8f1ecc __libc_start_main (/usr/lib/libc.so.6+0x25ecc)
#37 0x000055e016baefa5 _start (/home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin/clang-20+0x36acfa5)
clang: error: clang frontend command failed with exit code 134 (use -v to see invocation)
ClangBuiltLinux clang version 20.0.0git (https://github.com/llvm/llvm-project.git b1234ddbe2652aa7948242a57107ca7ab12fd2f8)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/nathan/tmp/cvise.NoOV35mHWo/install/llvm-bad/bin
Build config: +assertions
clang: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs.

@RKSimon
Copy link
Collaborator Author

RKSimon commented Aug 8, 2024

Thanks @nathanchance - I've confirmed thats addressed by my fix for the report from @ZequanWu - I'm going to push the fixed patch shortly.

RKSimon added a commit that referenced this pull request Aug 8, 2024
Ensure abds doesn't get truncated after type legalisation
RKSimon added a commit that referenced this pull request Aug 8, 2024
Always match ABD patterns pre-legalization, and use TargetLowering::expandABD to expand again during legalization.

abdu(lhs, rhs) -> sub(xor(sub(lhs, rhs), usub_overflow(lhs, rhs)), usub_overflow(lhs, rhs))
Alive2: https://alive2.llvm.org/ce/z/dVdMyv

REAPPLIED: Fix regression issue with "abs(ext(x) - ext(y)) -> zext(abd(x, y))" fold failing after type legalization
@bgra8
Copy link
Contributor

bgra8 commented Aug 8, 2024

@RKSimon my reduction is rather slow. I can post a reproducer but it is rather large (about 171K). Or wait for a bit longer?

@RKSimon
Copy link
Collaborator Author

RKSimon commented Aug 8, 2024

@bgra8 Please can you test 13d04fa to see if its fixed the issue?

@bgra8
Copy link
Contributor

bgra8 commented Aug 8, 2024

@bgra8 Please can you test 13d04fa to see if its fixed the issue?

Yes, the compilation is back under 3s. Thanks a lot!

@bgra8
Copy link
Contributor

bgra8 commented Aug 8, 2024

@RKSimon here's the repro for completion sake:

repro.cc:

extern "C" int abs(int);
struct a {
  a();
  int m_fn1() { return b; }
  int b : 4;
};
int c;
void cg() {
  a ci, cj;
  int ck = ci.m_fn1(), cl = cj.m_fn1();
  if (abs(ck - cl) <= c)
    a();
}

compilation command:

$ clang -c -O1 repro.cc -o /tmp/out

@RKSimon
Copy link
Collaborator Author

RKSimon commented Aug 8, 2024

Thanks @bgra8 - the reduced ir was very similar to c4e7728

TIFitis pushed a commit that referenced this pull request Aug 8, 2024
@bjope
Copy link
Collaborator

bjope commented Aug 12, 2024

For info: We have seen some problems with test/CodeGen/AArch64/abds.ll downstream after this patch was reapplied.

Looking at debug/print-after-all traces for @abd_ext_i128 I see that the ISel may create nodes in different order:

Legalizing node: t25: i128 = abds t9, t10
Analyzing result type: i128
Expand integer result: t25: i128 = abds t9, t10
Creating new node: t28: i32 = setcc t9, t10, setgt:ch
Creating new node: t29: i128 = sub t10, t9
Creating new node: t30: i128 = sub t9, t10
Creating new node: t31: i128 = select t28, t30, t29

vs

Legalizing node: t25: i128 = abds t9, t10
Analyzing result type: i128
Expand integer result: t25: i128 = abds t9, t10
Creating new node: t28: i32 = setcc t9, t10, setgt:ch
Creating new node: t29: i128 = sub t9, t10
Creating new node: t30: i128 = sub t10, t9
Creating new node: t31: i128 = select t28, t29, t30

And then it looks like the ISel scheduler may pick nodes in different order? And at least we get slightly different VReg usage in the MIR output after ISel. Later, at MachineCSE there is a limit on how far back it looks for common subexpressions, and we might end up either doing a CSE or not, depending on what the MIR looks like.

My current best thinking is that it is a difference depending on if I compile LLVM with clang or gcc. And then it probably is things like this in TargetLowering.cpp

  // abdu(lhs, rhs) -> or(usubsat(lhs,rhs), usubsat(rhs,lhs))
  if (!IsSigned && isOperationLegal(ISD::USUBSAT, VT))
    return DAG.getNode(ISD::OR, dl, VT,
                       DAG.getNode(ISD::USUBSAT, dl, VT, LHS, RHS),
                       DAG.getNode(ISD::USUBSAT, dl, VT, RHS, LHS));

and/or things like this in DagCombiner.cpp:

    SDValue ABD = DAG.getNode(ABDOpcode, DL, MaxVT,
                              DAG.getNode(ISD::TRUNCATE, DL, MaxVT, Op0),
                              DAG.getNode(ISD::TRUNCATE, DL, MaxVT, Op1));

that makes a difference since the order in which arguments are evaluated isn't well-defined.
Generally, nestled calls to getNode like that is nasty when comparing results from LLVM built with gcc vs clang.

@RKSimon
Copy link
Collaborator Author

RKSimon commented Aug 12, 2024

@bjope If you can confirm these go away if we pull out the inner getNode() calls then we can make the change - but given how prevalent this is in the codebase, I don't know what we'd do to address it completely.

@bjope
Copy link
Collaborator

bjope commented Aug 12, 2024

@bjope If you can confirm these go away if we pull out the inner getNode() calls then we can make the change - but given how prevalent this is in the codebase, I don't know what we'd do to address it completely.

I'm analysing it further, and will prepare something for this specific case (if my current suspicion ends up being correct).

Had been nice with some kind of checked (clang-tidy) that would detect the "bad" coding pattern. But I don't know really if that is easy/feasible to implement.
I often end up comparing debug outputs from different builds (we sometimes use gcc when building opt/llc in various automatic builds, and then I use clang myself and end up looking at diffs, and get lots of irrelevant diffs due to argument evaluation order. This time I think it actually impacted the backend optimizations as well and not only the order of debug printouts etc.

@bjope
Copy link
Collaborator

bjope commented Aug 12, 2024

@bjope If you can confirm these go away if we pull out the inner getNode() calls then we can make the change - but given how prevalent this is in the codebase, I don't know what we'd do to address it completely.

I'm analysing it further, and will prepare something for this specific case (if my current suspicion ends up being correct).

Had been nice with some kind of checked (clang-tidy) that would detect the "bad" coding pattern. But I don't know really if that is easy/feasible to implement. I often end up comparing debug outputs from different builds (we sometimes use gcc when building opt/llc in various automatic builds, and then I use clang myself and end up looking at diffs, and get lots of irrelevant diffs due to argument evaluation order. This time I think it actually impacted the backend optimizations as well and not only the order of debug printouts etc.

Turns out those diffs related to argument evaluation order was irrelevant for the failed test.
This pull request show what really caused the problem downstream: #102915
We've had some fixes in ScheduleDAG for many years, that impacted the abds.ll test case.

kstoimenov pushed a commit to kstoimenov/llvm-project that referenced this pull request Aug 15, 2024
…100810

Extend test coverage for llvm#92576 - copied from existing x86 tests
kstoimenov pushed a commit to kstoimenov/llvm-project that referenced this pull request Aug 15, 2024
This fixes a problem if abd nodes are generated more readily (llvm#92576).
The folding of abd nodes into abdl needs to check that the inputs are
the correct form of vector. The added test requires vector legalization
to occur in order to hit the combine at the wrong time.
kstoimenov pushed a commit to kstoimenov/llvm-project that referenced this pull request Aug 15, 2024
Always match ABD patterns pre-legalization, and use TargetLowering::expandABD to expand again during legalization.

abdu(lhs, rhs) -> sub(xor(sub(lhs, rhs), usub_overflow(lhs, rhs)), usub_overflow(lhs, rhs))
Alive2: https://alive2.llvm.org/ce/z/dVdMyv
kstoimenov pushed a commit to kstoimenov/llvm-project that referenced this pull request Aug 15, 2024
kstoimenov pushed a commit to kstoimenov/llvm-project that referenced this pull request Aug 15, 2024
Ensure abds doesn't get truncated after type legalisation
kstoimenov pushed a commit to kstoimenov/llvm-project that referenced this pull request Aug 15, 2024
Always match ABD patterns pre-legalization, and use TargetLowering::expandABD to expand again during legalization.

abdu(lhs, rhs) -> sub(xor(sub(lhs, rhs), usub_overflow(lhs, rhs)), usub_overflow(lhs, rhs))
Alive2: https://alive2.llvm.org/ce/z/dVdMyv

REAPPLIED: Fix regression issue with "abs(ext(x) - ext(y)) -> zext(abd(x, y))" fold failing after type legalization
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants