[llvm-bugs] [Bug 138178] SLP vectorizer crashes when built with hardening

[LLVM Bugs via llvm-bugs]

Issue	138178
Summary	SLP vectorizer crashes when built with hardening
Labels	llvm:SLPVectorizer
Assignees	alexey-bataev
Reporter	alexfh

    Similarly to https://github.com/llvm/llvm-project/issues/137164, clang built with hardened libc++ (`-D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_DEBUG`) crashes on the input below due to an incorrect comparator.
```
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

%struct.widget = type { %struct.baz }
%struct.baz = type { [3 x float] }

define i1 @snork({ <2 x float>, float } %arg, <2 x float> %arg1, i1 %arg2, ptr %arg3) personality ptr null {
bb:
  %alloca = alloca %struct.widget, align 4
  %alloca4 = alloca { <2 x float>, float }, align 8
  %extractvalue = extractvalue { <2 x float>, float } %arg, 0
  store <2 x float> %arg1, ptr %alloca, align 4
  store <2 x float> %arg1, ptr %alloca4, align 8
  %extractelement = extractelement <2 x float> %extractvalue, i64 0
  br i1 %arg2, label %bb8, label %bb5

bb5: ; preds = %bb
  %load = load volatile { <2 x float>, float }, ptr %alloca4, align 8
  %load6 = load volatile { <2 x float>, float }, ptr %alloca, align 8
  %load7 = load float, ptr %arg3, align 4
  br label %bb8

bb8: ; preds = %bb5, %bb
  %phi = phi float [ %load7, %bb5 ], [ %extractelement, %bb ]
  %fpext = fpext float %phi to double
  %call = call ptr @spam(ptr %alloca)
  %load9 = load float, ptr %call, align 4
  %fpext10 = fpext float %load9 to double
  %call11 = call i32 (ptr, ptr, ...) @fprintf(ptr null, ptr null, double %fpext, double %fpext10, double 0.000000e+00)
  %load12 = load float, ptr %alloca4, align 8
  %fpext13 = fpext float %load12 to double
  %call14 = call i32 (ptr, ptr, ...) @fprintf(ptr null, ptr null, double 0.000000e+00, double %fpext13, double 0.000000e+00)
  ret i1 false
}

declare i32 @fprintf(ptr, ptr, ...)

define ptr @spam(ptr %arg) {
bb:
  %call = call ptr @zot(ptr %arg, i64 1)
  ret ptr %call
}

define ptr @zot(ptr %arg, i64 %arg1) {
bb:
 %getelementptr = getelementptr [3 x float], ptr %arg, i64 0, i64 %arg1
  ret ptr %getelementptr
}

; uselistorder directives
uselistorder ptr null, { 1, 2, 3, 4, 5, 6, 0 }
uselistorder ptr @fprintf, { 1, 0 }
```

This reproduces with recent LLVM revisions (e.g. deae5eef7147c5ad3acff612ab0ed00e2186d9a5).

Stack trace:
```
 #4 0x00007f03dda9ddf7 abort
 #5 0x0000563a3b243da6 void std::__u::__check_strict_weak_ordering_sorted<llvm::Value**, llvm::function_ref<bool (llvm::Value*, llvm::Value*)>>(llvm::Value**, llvm::Value**, llvm::function_ref<bool (llvm::Value*, llvm::Value*)>&) SLPVectorizer.cpp:0:0
 #6 0x0000563a3b1d847f bool tryToVectorizeSequence<llvm::Value>(llvm::SmallVectorImpl<llvm::Value*>&, llvm::function_ref<bool (llvm::Value*, llvm::Value*)>, llvm::function_ref<bool (llvm::Value*, llvm::Value*)>, llvm::function_ref<bool (llvm::ArrayRef<llvm::Value*>, bool)>, bool, llvm::slpvectorizer::BoUpSLP&) SLPVectorizer.cpp:0:0
 #7 0x0000563a3b1cc810 llvm::SLPVectorizerPass::vectorizeChainsInBlock(llvm::BasicBlock*, llvm::slpvectorizer::BoUpSLP&)
 #8 0x0000563a3b1ca278 llvm::SLPVectorizerPass::runImpl(llvm::Function&, llvm::ScalarEvolution*, llvm::TargetTransformInfo*, llvm::TargetLibraryInfo*, llvm::AAResults*, llvm::LoopInfo*, llvm::DominatorTree*, llvm::AssumptionCache*, llvm::DemandedBits*, llvm::OptimizationRemarkEmitter*)
 #9 0x0000563a3b1c9998 llvm::SLPVectorizerPass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&)
#10 0x0000563a3a154432 llvm::detail::PassModel<llvm::Function, llvm::SLPVectorizerPass, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&)
#11 0x0000563a3bfda619 llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&)
#12 0x0000563a36a14cb2 llvm::detail::PassModel<llvm::Function, llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>>, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&)
#13 0x0000563a3bfdd67d llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&)
#14 0x0000563a36a109b2 llvm::detail::PassModel<llvm::Module, llvm::ModuleToFunctionPassAdaptor, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&)
#15 0x0000563a3bfd98a0 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&)
#16 0x0000563a36a0dc68 (anonymous namespace)::EmitAssemblyHelper::RunOptimizationPipeline(clang::BackendAction, std::__u::unique_ptr<llvm::raw_pwrite_stream, std::__u::default_delete<llvm::raw_pwrite_stream>>&, std::__u::unique_ptr<llvm::ToolOutputFile, std::__u::default_delete<llvm::ToolOutputFile>>&, clang::BackendConsumer*) BackendUtil.cpp:0:0
#17 0x0000563a36a0527c clang::emitBackendOutput(clang::CompilerInstance&, clang::CodeGenOptions&, 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*)
#18 0x0000563a366e49ca clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&)
#19 0x0000563a375c89e8 clang::ParseAST(clang::Sema&, bool, bool)
#20 0x0000563a3731848a clang::FrontendAction::Execute()
#21 0x0000563a3729242d clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
#22 0x0000563a366e37eb clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
#23 0x0000563a366d7920 cc1_main(llvm::ArrayRef<char const*>, char const*, void*)
```

_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs