User Details
- User Since
- Jul 10 2012, 10:35 AM (514 w, 6 d)
Today
And finally a reduced test case:
$ cat q.cc
struct S {
template<int N> bool f() const;
};
int f(const S& s) {
int d = 0;
if (s.f<1>()) ++d;
// 4998 lines skipped
if (s.f<5000>()) ++d;
if (d == 0) {
return s.f<-1>();
}
return 0;}
$ ./clang-11004 --target=x86_64--linux-gnu -O1 -fslp-vectorize -c -xc++
q.cc -o q.o -ftime-report
... Pass execution timing report ...
-------------------------------------------------------------------------
Total Execution Time: 8.7398 seconds (8.8367 wall clock)
Fri, May 20
No reduced test case, but one observation is that most samples in the slow version are around this (preexisting code):
Thu, May 19
I've noticed that this patch (7ea03f0b4e4ec5d91d48ba2976f5adc299089ffd) significantly increases compile time for a certain type of code (functions with a large number of branches on top level). In extreme cases (generated code with really large functions) this leads to tens of minutes of time spent in SLP vectorizer:
===-------------------------------------------------------------------------===
... Pass execution timing report ...
===-------------------------------------------------------------------------===
Total Execution Time: 1895.1082 seconds (1895.2216 wall clock)Mon, May 9
The last recommit of this patch (8b48223447311af8b3022697dd58858e1ce6975f "Recommit ""[VPlan] Remove uneeded needsVectorIV check.""") causes the compiler to crash on some of our code. A reduced test case:
$ cat q.cc int a[2]; int b; bool c() { bool d; for (int e; e; e--) { d = !d; b += d ?: a[e]; } return b; } $ ./clang -cc1 -triple x86_64--linux-gnu -emit-obj -O2 -vectorize-loops q.cc Stack dump: 0. Program arguments: ./clang -cc1 -triple x86_64--linux-gnu -emit-obj -O2 -vectorize-loops q.cc 1. <eof> parser at end of file 2. Optimizer #0 0x000055cb5104bfa8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (./clang+0x6e4bfa8) #1 0x000055cb5104c3c5 SignalHandler(int) (./clang+0x6e4c3c5) #2 0x00007f464c15b750 __restore_rt (/usr/grte/v5/lib64/libpthread.so.0+0x15750) #3 0x000055cb4d2f15fc llvm::VPlanTransforms::optimizeInductions(llvm::VPlan&, llvm::ScalarEvolution&) (./clang+0x30f15fc) #4 0x000055cb4d2eae74 llvm::LoopVectorizationPlanner::buildVPlanWithVPRecipes(llvm::VFRange&, llvm::SmallPtrSetImpl<llvm::Instruction*>&, llvm::MapVector<llvm::Instruction*, llvm::Instruction*, llvm::DenseMap<llvm::Instruction*, unsigned int, llvm::DenseMapInfo<llvm::Instruction*, void>, llvm::detail::DenseMapPair<llvm::Instruction*, unsigned int> >, std::__u::vector<std::__u::pair<llvm::Instruction*, llvm::Instruction*>, std::__u::allocator<std::__u::pair<llvm::Instruction*, llvm::Instruction*> > > > const&) (./clang+0x30eae74) #5 0x000055cb4d2e903b llvm::LoopVectorizationPlanner::buildVPlansWithVPRecipes(llvm::ElementCount, llvm::ElementCount) (./clang+0x30e903b) #6 0x000055cb4e865734 llvm::LoopVectorizePass::processLoop(llvm::Loop*) (.cold) (./clang+0x4665734) #7 0x000055cb4d143dcf llvm::LoopVectorizePass::runImpl(llvm::Function&, llvm::ScalarEvolution&, llvm::LoopInfo&, llvm::TargetTransformInfo&, llvm::DominatorTree&, llvm::BlockFrequencyInfo&, llvm::TargetLibraryInfo*, llvm::DemandedBits&, llvm::AAResults&, llvm::AssumptionCache&, std::__u::function<llvm::LoopAccessInfo const& (llvm::Loop&)>&, llvm::OptimizationRemarkEmitter&, llvm::ProfileSummaryInfo*) (./clang+0x2f43dcf) #8 0x000055cb4d143b7d llvm::LoopVectorizePass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (./clang+0x2f43b7d) #9 0x000055cb4d143832 llvm::detail::PassModel<llvm::Function, llvm::LoopVectorizePass, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Function> >::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (./clang+0x2f43832) #10 0x000055cb4db331fd llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function> >::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (./clang+0x39331fd) #11 0x000055cb4db32db2 llvm::detail::PassModel<llvm::Function, llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function> >, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Function> >::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (./clang+0x3932db2) #12 0x000055cb4d95fd16 llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (./clang+0x375fd16) #13 0x000055cb4d3cca92 llvm::detail::PassModel<llvm::Module, llvm::ModuleToFunctionPassAdaptor, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (./clang+0x31cca92) #14 0x000055cb4d1fdbe4 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (./clang+0x2ffdbe4) #15 0x000055cb4d233efd (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+0x3033efd) #16 0x000055cb4d22cee5 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, std::__u::unique_ptr<llvm::raw_pwrite_stream, std::__u::default_delete<llvm::raw_pwrite_stream> >) (./clang+0x302cee5) #17 0x000055cb4dd2e253 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (./clang+0x3b2e253) #18 0x000055cb4d226af4 clang::ParseAST(clang::Sema&, bool, bool) (./clang+0x3026af4) #19 0x000055cb4d308654 clang::FrontendAction::Execute() (./clang+0x3108654) #20 0x000055cb4d308472 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (./clang+0x3108472) #21 0x000055cb4d3082e5 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (./clang+0x31082e5) #22 0x000055cb4dcf3fca cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (./clang+0x3af3fca) #23 0x000055cb4d3cab81 ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) (./clang+0x31cab81) #24 0x000055cb4dbdddf2 main (./clang+0x39dddf2) #25 0x00007f464bfe98d3 __libc_start_main (/usr/grte/v5/lib64/libc.so.6+0x628d3) #26 0x000055cb4d3ca9fa _start (./clang+0x31ca9fa) Segmentation fault
Mar 24 2022
What's the right fix for this warning, using a literal of the same floating point type? Did you consider adding a fixit hint to the diagnostic?
Feb 10 2022
So far I have a stack trace from a release clang build:
#0 0x000055efacbf6c29 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) #1 0x000055efacbf7065 SignalHandler(int) #2 0x00007f1f25022750 __restore_rt #3 0x000055efa973210b (anonymous namespace)::LazyValueInfoImpl::getEdgeValue(llvm::Value*, llvm::BasicBlock*, llvm::BasicBlock*, llvm::Instruction*) #4 0x000055efa972db80 (anonymous namespace)::LazyValueInfoImpl::solve() (.llvm.1834014330660040286) #5 0x000055efa972a2dd (anonymous namespace)::LazyValueInfoImpl::getValueInBlock(llvm::Value*, llvm::BasicBlock*, llvm::Instruction*) #6 0x000055efa978882b runImpl(llvm::Function&, llvm::LazyValueInfo*, llvm::DominatorTree*, llvm::SimplifyQuery const&) #7 0x000055efa9787755 llvm::CorrelatedValuePropagationPass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) #8 0x000055efa97873b2 llvm::detail::PassModel<llvm::Function, llvm::CorrelatedValuePropagationPass, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Function> >::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) #9 0x000055efa983d69a llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function> >::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) #10 0x000055efa983d2b2 llvm::detail::PassModel<llvm::Function, llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function> >, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Function> >::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) #11 0x000055efa999414e llvm::CGSCCToFunctionPassAdaptor::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) #12 0x000055efa9993b32 llvm::detail::PassModel<llvm::LazyCallGraph::SCC, llvm::CGSCCToFunctionPassAdaptor, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) #13 0x000055efa9940a64 llvm::PassManager<llvm::LazyCallGraph::SCC, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) #14 0x000055efa99406f2 llvm::detail::PassModel<llvm::LazyCallGraph::SCC, llvm::PassManager<llvm::LazyCallGraph::SCC, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) #15 0x000055efa987de69 llvm::DevirtSCCRepeatedPass::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) #16 0x000055efa987dc52 llvm::detail::PassModel<llvm::LazyCallGraph::SCC, llvm::DevirtSCCRepeatedPass, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) #17 0x000055efa98934a0 llvm::ModuleToPostOrderCGSCCPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) #18 0x000055efa919ddb2 llvm::detail::PassModel<llvm::Module, llvm::ModuleToPostOrderCGSCCPassAdaptor, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) #19 0x000055efa8f4a1c4 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) #20 0x000055efa8f49e4a llvm::ModuleInlinerWrapperPass::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) #21 0x000055efa8f49c92 llvm::detail::PassModel<llvm::Module, llvm::ModuleInlinerWrapperPass, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) #22 0x000055efa8f4a1c4 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) #23 0x000055efa8f8c260 (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> >&) #24 0x000055efa8f84bb2 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, std::__u::unique_ptr<llvm::raw_pwrite_stream, std::__u::default_delete<llvm::raw_pwrite_stream> >) #25 0x000055efa9a4b8d1 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) #26 0x000055efa8f7e180 clang::ParseAST(clang::Sema&, bool, bool) #27 0x000055efa90338f5 clang::FrontendAction::Execute() #28 0x000055efa903372e clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) #29 0x000055efa90335a1 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) #30 0x000055efa9a15d58 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) #31 0x000055efa9112f7e ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) #32 0x000055efa98b2a2d main
I think, the last commit (ad2a0ccf8f9816fd7805138bbf582117246f5489) still has some problems. We are seeing sporadic clang crashes after this commit. I'm trying to confirm this by comparing this revision with the previous one and trying to get a test case.
Feb 7 2022
Jan 28 2022
Looks good. Thanks for the fix!
Jan 27 2022
I reduced our problematic file to a function with a couple thousand variables of a type containing a few std::function<>s. This can be demonstrated by this synthetic test case (compiled on x86-64 linux with libc++):
#include <functional>
#include <vector>
namespace n {Jan 24 2022
I found one particularly bad input. Here what time -v clang -fno-omit-frame-pointer -fcommon -no-canonical-prefixes -fdiagnostics-show-option -fmessage-length=0 -fno-exceptions -fbracket-depth=768 -fno-strict-aliasing -fmerge-all-constants -flax-vector-conversions=all -funsigned-char -Xclang=-fuse-ctor-homing -fcolor-diagnostics --cuda-host-only -faligned-allocation -fnew-alignment=8 -fshow-overloads=best -mllvm -disable-binop-extract-shuffle -fdebug-types-section -O2 -momit-leaf-frame-pointer -ffp-contract=off --target=x86_64-unknown-linux-gnu -fno-unique-section-names -maes -m64 -mcx16 -msse4.2 -mpclmul -mprefer-vector-width=128 -gmlt -gz=zlib -fdebug-default-version=5 -fsanitize=address,bool,bounds,builtin,float-cast-overflow,integer-divide-by-zero,null,return,returns-nonnull-attribute,shift-exponent,signed-integer-overflow,unreachable,vla-bound -fsanitize-address-globals-dead-stripping -fsanitize-trap=null -fno-sanitize-recover=all -fno-omit-frame-pointer -fsized-deallocation -fPIE -fdirect-access-external-data -ffunction-sections -fdata-sections -pthread -fno-sanitize-trap=all -std=gnu++17 -stdlib=libc++ -Wno-deprecated-declarations -Wno-inconsistent-missing-override -save-stats -c q.cc -o q.o says 1. at rG74db5c8c95e2aed40d288bb2df92eb859b87c827 (with the new behavior disabled) and 2. at rG80532ebb508d0ca62f96df5f253db8caed969397 (right before rG74db5c8c95e2aed40d288bb2df92eb859b87c827):
1
User time (seconds): 190.92 System time (seconds): 2.16 Percent of CPU this job got: 99% Elapsed (wall clock) time (h:mm:ss or m:ss): 3:13.10 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 4926000 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 27080 Voluntary context switches: 8 Involuntary context switches: 579 Swaps: 0 File system inputs: 0 File system outputs: 54168 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0
2
User time (seconds): 255.60 System time (seconds): 8.09 Percent of CPU this job got: 99% Elapsed (wall clock) time (h:mm:ss or m:ss): 4:23.71 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 27272308 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 32213 Voluntary context switches: 8 Involuntary context switches: 779 Swaps: 0 File system inputs: 0 File system outputs: 54168 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0
Jan 21 2022
Hi Jeremy,
after this patch we see significantly increased compile-time memory usage, which makes a large number of targets to fail to compile with the (already quite large) memory limit we have on our build cluster. I'll try to get specific numbers and maybe an example, but it seems like this patch has raised enough concerns to maybe flip the default back while all of these are being addressed?
We've started seeing some tests dying with SIGILL (illegal instruction) after this patch. I'm working on a reduced repro, but please take a look, if you can find any issues yourself.
Jan 17 2022
Do you need help landing the change?
Looks good with one suggestion.
I wonder what motivated the patch. Is this a performance optimization? If so, do you have any measurements?
Dec 16 2021
Dec 15 2021
(general discussion, not necessarily related to this patch)
Dec 14 2021
Dec 13 2021
A bit cleaner test case:
Dec 12 2021
I observe the problem on Linux on x86-64.
I've created a standalone test case for the issue:
Dec 10 2021
Hi Florian,
Nov 22 2021
Reduced the problematic file to this:
FYI, the last re-commit of this patch introduced another compile time regression. See https://reviews.llvm.org/rGc93f93b2e3f28997f794265089fb8138dd5b5f13 for more information.
Nov 19 2021
Nov 17 2021
Nov 15 2021
Oct 20 2021
Reduced the test further to:
struct k {
~k() __attribute__((annotate(""))) {}
};
void m() { k(); }Reduced test case:
template <class a> void b(a);
template <typename c> class d {
public:
class e {
public:
c *f();
};
e *g();
};
template <class> class j;
template <class h, class... i> class j<h(i...)> {
public:
class k {
public:
k(int *);
~k();
};
int n();
d<int *> l;
};
template <class h, class... i> int j<h(i...)>::n() {
auto m = l.g()->f();
k a(*m);
b(a);
}
template <class h, class... i>
j<h(i...)>::k::~k() __attribute__((annotate(""))) {}
class o {
int m_fn4();
j<int()> p;
};
int o::m_fn4() { p.n(); }Oct 19 2021
It looks like this patch causes clang to crash on valid code with the following stack trace:
#0 0x0000560442f12f45 SignalHandler(int) #1 0x00007ffac7c789a0 __restore_rt #2 0x0000560440083992 llvm::LazyCallGraph::Node::populateSlow() #3 0x0000560440082a60 llvm::LazyCallGraph::buildRefSCCs() #4 0x000056043fef166d llvm::ModuleToPostOrderCGSCCPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) #5 0x000056043f8852f2 llvm::detail::PassModel<llvm::Module, llvm::ModuleToPostOrderCGSCCPassAdaptor, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) #6 0x000056043f617204 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) #7 0x000056043f616e34 llvm::ModuleInlinerWrapperPass::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) #8 0x000056043f616cb2 llvm::detail::PassModel<llvm::Module, llvm::ModuleInlinerWrapperPass, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) #9 0x000056043f617204 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) #10 0x0000560440100459 (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> >&) #11 0x000056043f63dff7 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, std::__u::unique_ptr<llvm::raw_pwrite_stream, std::__u::default_delete<llvm::raw_pwrite_stream> >) #12 0x00005604400f6703 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) #13 0x000056043f638300 clang::ParseAST(clang::Sema&, bool, bool) #14 0x000056043f6f96d5 clang::FrontendAction::Execute() #15 0x000056043f6f9515 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) #16 0x000056043f6f9381 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) #17 0x00005604400b84f8 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) #18 0x000056043f7a7a79 ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) #19 0x000056043ff4b6f4 main #20 0x00007ffac7ae6bbd __libc_start_main #21 0x000056043f815679 _start
Working on a reduced test.
Oct 1 2021
Sep 29 2021
Sep 27 2021
We'd appreciate a prompt fix or a workaround. If neither is possible, please revert the commit while working on a proper solution.
Reduced test case:
Sep 26 2021
Sep 25 2021
Repeating my question from an earlier comment: would a header glob list (similar to how the format of the -checks= flag) be enough for the use cases folks have? On the one hand glob list doesn't support all the features of regular expressions, but are they all useful for matching paths? Glob list in clang-tidy currently supports set union (similar to regex |) and <any subsequence> - * (regex .*). If needed, the support can be expanded with ?, character classes, character ranges and/or other features of POSIX globs (https://man7.org/linux/man-pages/man7/glob.7.html). On the flipside, glob list has a cleaner syntax (no need to quote characters common in paths - like .), and allows to easily express exclusion of subsets. It should be a convenient tool to represent a set of files / directories. In comparison to the proposed header-filter + exclude-header-filter glob list makes it possible to naturally express restrictions similar to "everything under a/ (except for everything under a/b/ (except for everything under a/b/c/))" - a/,-a/b/,a/b/c/.
Sep 24 2021
FYI, we see a ~5x increase in compile time on some of our code (mainly on some large protobuf-generated files) after rG8ba2adcf9e54b34ba8efa73ac0d81a1192e4f614. We're working on an isolated test case.
Sep 15 2021
Sep 1 2021
Aug 31 2021
Aug 30 2021
Some of our tests started failing after rG84cbd71c95923f9912512f3051c6ab548a99e016 (and previously after rGa28234e37af877b2b4a23c2091c27fa18c155f9a). Could you revert it again while we're working on a test case?
Aug 27 2021
Thanks for the prompt fix! One nit.
Aug 25 2021
Aug 23 2021
I think, it's the right first step, and if there's a need to make the transformation support more use cases like checking the result of malloc for null, that can be added as a separate step.
Looks good to me!
Aug 20 2021
Aug 19 2021
This commit seems to cause memory usage (rss) increase in MariaDB's mysqld by a factor of 4. Looking back into the history, I found that the previous commit here caused the same regression, but we quickly picked up the revert and moved on. Now I'm trying to isolate the problem, but it's taking time.
So far, my sole hypothesis is that malloc + memset of a smaller size can still be converted to calloc. But I have no evidence so far. Naive attempts to synthetically reproduce this didn't work. Maybe this only happens when some UB is in place, but again, I have nothing to back this up.
Aug 18 2021
@RKSimon we've discovered that this commit is causing substantial performance regressions (~11% runtime) of some of our benchmarks on different x86 microarchitectures (haswell, skylake). @wmi is trying to get an isolated test.
Jul 30 2021
Looking at this once again, I'm pretty sure that reverting this is much safer than trying to fix forward. Unless there's a really trivial fix to the outstanding issues, I'll revert this later today.
Jul 29 2021
This commit changes the behavior of clang -E -P even when no -fminimize-whitespace is used. This breaks certain use cases like using clang to preprocess files for flex, which turns out to be sensitive to the presence of line breaks in places where C++ compilers aren't.
Jul 14 2021
Jul 13 2021
LG. I can commit the patch for you.
Jul 1 2021
I have no idea what this code is doing, but just based on the fact that it fixes the problem, it looks good to me ;)
The patch fixes the segfaults we've seen after https://reviews.llvm.org/D103458.
Jun 28 2021
Function-wise the patch looks good, but I'm somewhat concerned about silently breaking users. At the very least there should be a relevant entry in the release notes.
I thought I sent this batch of comments loong ago =\
Jun 10 2021
May 9 2021
BTW, any ideas why "patch application failed"? (See the Build status in the Diff Detail section)
Thanks for the great work! This is mostly looking fine, but I've added a few comments. I could only make a quite superficial review so far, but I'll try to take a deeper look into this soon.
Apr 12 2021
LG with a couple of nits.
Mar 10 2021
Looks good. Thanks for the fix! I'll get it landed for you.