User Details
- User Since
- Sep 5 2017, 3:03 AM (316 w, 6 d)
Aug 2 2023
LGTM
Jul 18 2023
Jun 22 2023
Jun 14 2023
This change causes a miscompile. Here's an example: https://alive2.llvm.org/ce/z/5rPFgH
With this change opt -passes=instcombine transforms the following IR:
define i1 @test(i64 %arg) { %sitofp = sitofp i64 %arg to float %fmul = fmul float %sitofp, 0x7FF0000000000000 %fcmp = fcmp uno float %fmul, 0.000000e+00 ret i1 %fcmp }
into
define i1 @test(i64 %arg) { ret i1 false }
That's not correct because fcmp uno returns true if either argument is NaN and by IEEE-754 multiplication of infinity (aka 0x7FF0000000000000) and 0 (sitofp i64 %arg to float with %arg == 0) is NaN. Alive2 points out exactly this case.
Please fix or revert ASAP.
May 12 2023
Maybe a new API is inorder? isSafeToSpeculativelyExecuteConst so that things like hoisting (which don't change the operands) can use the improve analysis but not things like GuardWidening or CVP.
May 11 2023
Feb 27 2023
@ABataev thank you!
Feb 24 2023
This patch is causing a crash even after the 26fec4e845a833214d2b0036ea90f1b1c2418d50
IR:
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128-ni:1-p2:32:8:8:32-ni:2" target triple = "x86_64-unknown-linux-gnu"
Jul 30 2022
The change seems reasonable.
Jun 28 2022
Jun 2 2022
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