User Details
- User Since
- Sep 5 2017, 3:03 AM (246 w, 3 d)
Feb 17 2022
Feb 16 2022
Jan 5 2022
Fixed lint checks, added a couple of tests and addressed a comment.
Jan 4 2022
Fixed formatting.
Oct 1 2021
D110752 is not corrupting IR, it happened because we were looking at a constant's users, which is not a thing that makes sense to do (e.g. look at all users of the constant false).
And another one: https://lab.llvm.org/buildbot/#/builders/5/builds/12562/steps/13/logs/stdio
******************** TEST 'LLVM :: CodeGen/X86/misched-new.ll' FAILED ******************** Script: -- : 'RUN: at line 1'; /b/sanitizer-x86_64-linux-fast/build/llvm_build_asan/bin/llc < /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/test/CodeGen/X86/misched-new.ll -mtriple=x86_64-- -mcpu=core2 -x86-early-ifcvt -enable-misched -misched=shuffle -misched-bottomup -verify-machineinstrs | /b/sanitizer-x86_64-linux-fast/build/llvm_build_asan/bin/FileCheck /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/test/CodeGen/X86/misched-new.ll : 'RUN: at line 4'; /b/sanitizer-x86_64-linux-fast/build/llvm_build_asan/bin/llc < /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/test/CodeGen/X86/misched-new.ll -mtriple=x86_64-- -mcpu=core2 -x86-early-ifcvt -enable-misched -misched=shuffle -misched-topdown -verify-machineinstrs | /b/sanitizer-x86_64-linux-fast/build/llvm_build_asan/bin/FileCheck /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/test/CodeGen/X86/misched-new.ll --check-prefix TOPDOWN -- Exit Code: 2 Command Output (stderr): -- ================================================================= ==632==ERROR: AddressSanitizer: use-after-poison on address 0x62100006ab10 at pc 0x0000096c272a bp 0x7ffcd29574b0 sp 0x7ffcd29574a8 READ of size 8 at 0x62100006ab10 thread T0 #0 0x96c2729 in getParent /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/CodeGen/MachineBasicBlock.h:225:53 #1 0x96c2729 in llvm::DominatorTreeBase<llvm::MachineBasicBlock, false>::getNode(llvm::MachineBasicBlock const*) const /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/Support/GenericDomTree.h:352:5 #2 0x93d9b32 in getNode /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/CodeGen/MachineDominators.h:171:16 #3 0x93d9b32 in (anonymous namespace)::updateDomTree(llvm::MachineDominatorTree*, (anonymous namespace)::SSAIfConv const&, llvm::ArrayRef<llvm::MachineBasicBlock*>) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/CodeGen/EarlyIfConversion.cpp:814:41 #4 0x93d1e95 in tryConvertIf /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/CodeGen/EarlyIfConversion.cpp:1037:5 #5 0x93d1e95 in (anonymous namespace)::EarlyIfConverter::runOnMachineFunction(llvm::MachineFunction&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/CodeGen/EarlyIfConversion.cpp:1071:9 #6 0x970dd68 in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/CodeGen/MachineFunctionPass.cpp:72:13 #7 0xa54710c in llvm::FPPassManager::runOnFunction(llvm::Function&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1439:27 #8 0xa562670 in llvm::FPPassManager::runOnModule(llvm::Module&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1485:16 #9 0xa549328 in runOnModule /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1554:27 #10 0xa549328 in llvm::legacy::PassManagerImpl::run(llvm::Module&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:542:44 #11 0x4ca65a0 in compileModule /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/tools/llc/llc.cpp:687:8 #12 0x4ca65a0 in main /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/tools/llc/llc.cpp:388:22 #13 0x7f16128a009a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a) #14 0x4be6899 in _start (/b/sanitizer-x86_64-linux-fast/build/llvm_build_asan/bin/llc+0x4be6899)
The use-after-poison makes me think they're making a query about a block that is already deleted.
It looks like it has found an actual bug: https://lab.llvm.org/buildbot/#/builders/70/builds/12409/steps/10/logs/stdio
clang++: /b/sanitizer-x86_64-linux-autoconf/build/llvm-project/llvm/include/llvm/Support/GenericDomTree.h:353: llvm::DomTreeNodeBase<NodeT>* llvm::DominatorTreeBase<NodeT, IsPostDom>::getNode(const NodeT*) const [with NodeT = llvm::BasicBlock; bool IsPostDom = false]: Assertion `(!BB || !BB->getParent() || BB->getParent() == Parent) && "A node from another function!"' failed. PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: /b/sanitizer-x86_64-linux-autoconf/build/tsan_debug_build/bin/clang++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Transforms/Instrumentation -I/b/sanitizer-x86_64-linux-autoconf/build/llvm-project/llvm/lib/Transforms/Instrumentation -Iinclude -I/b/sanitizer-x86_64-linux-autoconf/build/llvm-project/llvm/include -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -fdiagnostics-color -ffunction-sections -fdata-sections -O2 -g -DNDEBUG -fno-exceptions -fno-rtti -UNDEBUG -std=c++14 -MD -MT lib/Transforms/Instrumentation/CMakeFiles/LLVMInstrumentation.dir/DataFlowSanitizer.cpp.o -MF lib/Transforms/Instrumentation/CMakeFiles/LLVMInstrumentation.dir/DataFlowSanitizer.cpp.o.d -o lib/Transforms/Instrumentation/CMakeFiles/LLVMInstrumentation.dir/DataFlowSanitizer.cpp.o -c /b/sanitizer-x86_64-linux-autoconf/build/llvm-project/llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp 1. <eof> parser at end of file 2. Optimizer #0 0x00005654354a733c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /b/sanitizer-x86_64-linux-autoconf/build/llvm-project/llvm/lib/Support/Unix/Signals.inc:569:3 #1 0x00005654354a53d4 llvm::sys::RunSignalHandlers() /b/sanitizer-x86_64-linux-autoconf/build/llvm-project/llvm/lib/Support/Signals.cpp:97:20 #2 0x00005654354a5949 llvm::sys::CleanupOnSignal(unsigned long) /b/sanitizer-x86_64-linux-autoconf/build/llvm-project/llvm/lib/Support/Unix/Signals.inc:361:31 #3 0x000056543540d3a8 HandleCrash /b/sanitizer-x86_64-linux-autoconf/build/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:74:27 #4 0x000056543540d3a8 CrashRecoverySignalHandler(int) /b/sanitizer-x86_64-linux-autoconf/build/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:389:62 #5 0x00007fbbaaebd730 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12730) #6 0x00007fbbaa7a37bb raise (/lib/x86_64-linux-gnu/libc.so.6+0x377bb) #7 0x00007fbbaa78e535 abort (/lib/x86_64-linux-gnu/libc.so.6+0x22535) #8 0x00007fbbaa78e40f (/lib/x86_64-linux-gnu/libc.so.6+0x2240f) #9 0x00007fbbaa79c102 (/lib/x86_64-linux-gnu/libc.so.6+0x30102) #10 0x0000565434c0f580 llvm::DominatorTreeBase<llvm::BasicBlock, false>::operator[](llvm::BasicBlock const*) const /b/sanitizer-x86_64-linux-autoconf/build/llvm-project/llvm/include/llvm/Support/GenericDomTree.h:363:22 #11 0x0000565434c0fec5 llvm::DominatorTreeBase<llvm::BasicBlock, false>::properlyDominates(llvm::BasicBlock const*, llvm::BasicBlock const*) const /b/sanitizer-x86_64-linux-autoconf/build/llvm-project/llvm/include/llvm/Support/GenericDomTree.h:947:51 #12 0x0000565434c0fec5 llvm::DominatorTreeBase<llvm::BasicBlock, false>::properlyDominates(llvm::BasicBlock const*, llvm::BasicBlock const*) const /b/sanitizer-x86_64-linux-autoconf/build/llvm-project/llvm/include/llvm/Support/GenericDomTree.h:938:6 #13 0x0000565435235a9d isLoadInvariantInLoop /b/sanitizer-x86_64-linux-autoconf/build/llvm-project/llvm/lib/Transforms/Scalar/LICM.cpp:1095:61 #14 0x0000565435235a9d llvm::canSinkOrHoistInst(llvm::Instruction&, llvm::AAResults*, llvm::DominatorTree*, llvm::Loop*, llvm::AliasSetTracker*, llvm::MemorySSAUpdater*, bool, llvm::SinkAndHoistLICMFlags*, llvm::OptimizationRemarkEmitter*) (.part.845) /b/sanitizer-x86_64-linux-autoconf/build/llvm-project/llvm/lib/Transforms/Scalar/LICM.cpp:1187:30 #15 0x000056543523bf29 llvm::hoistRegion(llvm::DomTreeNodeBase<llvm::BasicBlock>*, llvm::AAResults*, llvm::LoopInfo*, llvm::DominatorTree*, llvm::BlockFrequencyInfo*, llvm::TargetLibraryInfo*, llvm::Loop*, llvm::MemorySSAUpdater*, llvm::ScalarEvolution*, llvm::ICFLoopSafetyInfo*, llvm::SinkAndHoistLICMFlags&, llvm::OptimizationRemarkEmitter*, bool) /b/sanitizer-x86_64-linux-autoconf/build/llvm-project/llvm/lib/Transforms/Scalar/LICM.cpp:909:49 #16 0x0000565435240e04 (anonymous namespace)::LoopInvariantCodeMotion::runOnLoop(llvm::Loop*, llvm::AAResults*, llvm::LoopInfo*, llvm::DominatorTree*, llvm::BlockFrequencyInfo*, llvm::TargetLibraryInfo*, llvm::TargetTransformInfo*, llvm::ScalarEvolution*, llvm::MemorySSA*, llvm::OptimizationRemarkEmitter*, bool) (.part.877) /b/sanitizer-x86_64-linux-autoconf/build/llvm-project/llvm/lib/Transforms/Scalar/LICM.cpp:436:38 #17 0x00005654352424c0 llvm::LICMPass::run(llvm::Loop&, llvm::AnalysisManager<llvm::Loop, llvm::LoopStandardAnalysisResults&>&, llvm::LoopStandardAnalysisResults&, llvm::LPMUpdater&) /b/sanitizer-x86_64-linux-autoconf/build/llvm-project/llvm/lib/Transforms/Scalar/LICM.cpp:274:3 <...>
Sep 30 2021
Now D110751 is on top of this change.
Rebased it on top of D110752.
Rebased on top of new version of D110751. Now it should be easier to understand what's going on with the test.
That was wrong diff.
Updated testcase to make it clearer how this patch impacts it.
Sep 29 2021
Since SimpleLoopUnswitch is known to break this assertion, I'm going to land this patch only together with D110752.
Sep 23 2021
Sep 16 2021
Sep 15 2021
Removed the pair of {} that became unnecessary.
Sep 13 2021
I'll commit it.
Sep 2 2021
Sep 1 2021
Merged stringAttrAsInt into getStringFnAttrAsInt.
Addressed the comments:
- Got rid of CallBase::getFnAttr change, moved that part into a local helper function.
- stringAttrAsInt isn't a template now.
Aug 31 2021
Jul 13 2021
LGTM
Jul 12 2021
- Since you're replacing an OR chain you need to re-implement std::disjunction, not std::conjunction (no s at the end), which you mostly did, except for the name and the (2).
- According to the specification std::disjunction should return std::false_type for an empty argument list. I.e. here you should use std::false_type instead:
template <typename... Conds> struct conjunctions : std::true_type {};
Also please add a couple of tests for your llvm::disjunction implementation to llvm/unittests/Support/TypeTraitsTest.cpp.
Jul 7 2021
LGTM
Jun 7 2021
May 20 2021
LGTM
May 18 2021
Mar 30 2021
Mar 29 2021
Hi! This commit causes miscompilation.
Here's the test:
define i32 @foo(i32* %arg1, i1 %arg2, i1* %arg3, i1* %arg4) { bb: %tmp7 = icmp ne i1 %arg2, 0 %tmp9 = xor i1 %tmp7, true %tmp10 = or i1 %tmp7, %tmp9 br label %bb11
Sep 9 2020
Hi Roman!
I don't know if this information will help you, but after c9dc627331992b01b962103fad813810cba00696 on internal testing we started hitting following assertion at very low rate
llvm/include/llvm/ADT/DenseMap.h:408 assert(!FoundVal && "Key already in new map?");
Aug 11 2020
I checked it and it looks like if it compiles, everything should work just fine in presence of incomplete types.
LGTM
Jul 22 2020
May 27 2020
May 26 2020
Mar 6 2020
Mar 5 2020
Apparently, it breaks MSVC buildbots too, but it does it in a way I can't comprehend: looks like after my change MSVC instantiates all methods of BlockFrequencyInfoImpl, including ones that weren't instantiated before and which are incorrect for <MachineBasicBlock> instantiation. I don't have access to MSVC, so there's no way I'll figure out what's wrong with it and fix it.
Following resubmission of this patch:
commit 8975aa6ea8172963d6532caa8ed2a6f6e0074a02 Author: Daniil Suchkov <suc-daniil@yandex.ru> Date: Thu Mar 5 18:32:50 2020 +0700
Hi! I had to revert this patch because following test results in SIGSEGV and passes with the patch reverted (you can find it at llvm/test/Transforms/LoopRotate/freeze-crash.ll):
; RUN: opt -loop-rotate -disable-output %s
Hi! Unfortunately I had to revert this patch, see my comment here: https://reviews.llvm.org/rG952ad4701cf0d8da79789f6b83ddaa386c60d535
Mar 4 2020
Actually, this change will even help CheckBFIUnknownBlockQueries: since every missed update will result in a missing NodesMap entry, without exclusion of cases when new BB happens to be in the same address where some old BB was.
Mar 3 2020
You mean we don't need to update BFI in non-asserting mode? It's not just for verification, it's required for correctness.
Mar 1 2020
Got rid of all const_casts except one, which was moved into CallbackVH's constructor.
Feb 28 2020
One thing I don't understand is why three out of four kinds of VHs perform the const_cast, not the ValueHandleBase. I think it's time to change that (and by doing so, allow CallbackVH accept const pointers too).
Given that three out of four VH kinds already perform const_cast inside, I think it makes sense to add one to CallbackVH too.