User Details
- User Since
- Jan 3 2020, 4:17 AM (55 w, 1 h)
Tue, Jan 19
I apologize, but I was not having any luck at creating a test case that wasn't constant folded away.
Mon, Jan 18
I've been unable to create a reproducer because of other optimizations getting in the way, but I'm seeing a case of infinite loops in inst combine due to both CmpLHS and CmpRHS being constants.
Thanks for addressing the issues shchenz! I'm glad you figured out the use-of-uninitialized-value because that one confused me. I'm finishing my workday for the day, so I can rerun the patch tomorrow. Alternatively, all I know is that I had errors in my environment and that's what sanitizers showed, so you reproducing and fixing the issues is plenty I think.
I'm going to roll this back as it's causing build bot failures (in progress example here: http://45.33.8.238/win/31506/). Sanitizers show the following issues:
==9097==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x5628a1bd3d10 in llvm::PPCInstrInfo::getFMAPatterns(llvm::MachineInstr&, llvm::SmallVectorImpl<llvm::MachineCombinerPattern>&, bool) const third_party/llvm/llvm-project/llvm/lib/Target/PowerPC/PPCInstrIn fo.cpp:474:27 #1 0x5628a1bd7e6c in llvm::PPCInstrInfo::getMachineCombinerPatterns(llvm::MachineInstr&, llvm::SmallVectorImpl<llvm::MachineCombinerPattern>&, bool) const third_party/llvm/llvm-project/llvm/lib/Target/PowerP C/PPCInstrInfo.cpp:751:7 #2 0x5628a3291840 in combineInstructions third_party/llvm/llvm-project/llvm/lib/CodeGen/MachineCombiner.cpp:593:15 #3 0x5628a3291840 in (anonymous namespace)::MachineCombiner::runOnMachineFunction(llvm::MachineFunction&) third_party/llvm/llvm-project/llvm/lib/CodeGen/MachineCombiner.cpp:736:16 #4 0x5628a32f91a2 in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) third_party/llvm/llvm-project/llvm/lib/CodeGen/MachineFunctionPass.cpp:72:13 #5 0x5628a5e0dce7 in llvm::FPPassManager::runOnFunction(llvm::Function&) third_party/llvm/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1439:27 #6 0x5628a5e22f60 in llvm::FPPassManager::runOnModule(llvm::Module&) third_party/llvm/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1485:16 #7 0x5628a5e0f1d5 in runOnModule third_party/llvm/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1554:27 #8 0x5628a5e0f1d5 in llvm::legacy::PassManagerImpl::run(llvm::Module&) third_party/llvm/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:541:44 #9 0x56289f8dcb66 in compileModule(char**, llvm::LLVMContext&) third_party/llvm/llvm-project/llvm/tools/llc/llc.cpp:658:8
and
==1709==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7f155364a060 at pc 0x555a067755c4 bp 0x7fff9b909050 sp 0x7fff9b909048 READ of size 8 at 0x7f155364a060 thread T0 #0 0x555a067755c3 in operator[] third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/vector:1550:18 #1 0x555a067755c3 in llvm::PPCInstrInfo::shouldReduceRegisterPressure(llvm::MachineBasicBlock*, llvm::RegisterClassInfo*) const third_party/llvm/llvm-project/llvm/lib/Target/PowerPC/PPCInstrInfo.cpp:655:10 #2 0x555a07df5618 in combineInstructions third_party/llvm/llvm-project/llvm/lib/CodeGen/MachineCombiner.cpp:561:12 #3 0x555a07df5618 in (anonymous namespace)::MachineCombiner::runOnMachineFunction(llvm::MachineFunction&) third_party/llvm/llvm-project/llvm/lib/CodeGen/MachineCombiner.cpp:736:16 #4 0x555a07e54479 in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) third_party/llvm/llvm-project/llvm/lib/CodeGen/MachineFunctionPass.cpp:72:13 #5 0x555a0b360710 in llvm::FPPassManager::runOnFunction(llvm::Function&) third_party/llvm/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1439:27 #6 0x555a0b374470 in llvm::FPPassManager::runOnModule(llvm::Module&) third_party/llvm/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1485:16 #7 0x555a0b3616e0 in runOnModule third_party/llvm/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1554:27 #8 0x555a0b3616e0 in llvm::legacy::PassManagerImpl::run(llvm::Module&) third_party/llvm/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:541:44 #9 0x555a0461db8b in compileModule(char**, llvm::LLVMContext&) third_party/llvm/llvm-project/llvm/tools/llc/llc.cpp:658:8 #10 0x555a046183bf in main third_party/llvm/llvm-project/llvm/tools/llc/llc.cpp:363:22
Fri, Jan 15
Another naming convention correction.
Match LLVM naming convention.
Thu, Jan 14
Wed, Jan 13
Tue, Jan 5
No problem. https://reviews.llvm.org/D94132 is my fix CL. Please take a look if you have time. I just prepended ::mlir:: everywhere, but I didn't look deeply at the code (I'm running tests now, but they take a while for me).
I can handle this one, but just a note that this used Attribute instead of ::mlir::Attribute like all the other cases. This can fail then on any code not in an mlir namespace.
Dec 21 2020
Dec 16 2020
Dec 15 2020
Correct typo and add comment
Add test case
Add link to RFC and test case.
Dec 14 2020
Remove powi
Dec 11 2020
Dec 9 2020
Dec 8 2020
Dec 7 2020
Update comments.
Dec 4 2020
As a general matter of policy in LLVM, we do not bypass ongoing design discussions to unblock downstream users.
Pass an OpBuilder instead of an optional Listener.
Nov 30 2020
Nov 27 2020
Nov 25 2020
Nov 19 2020
No problem :) It's just unfortunate there weren't any tests using this to catch this.
Nov 18 2020
Only nits.
Nov 11 2020
Add a test
Nov 10 2020
Nov 9 2020
Nov 3 2020
Somehow I submitted this already, but the commit detached from this review. I am abandoning this change, so it goes away, but I will handle feedback in a follow up commit.
Oct 30 2020
I'm going to land this with these changes because the code was already in another commit and didn't receive any strong negative feedback, so I'm hoping there are only nits left if anything. I will follow up on any comments.
Oct 29 2020
Reformat each block of code in own namespace.
Rework to lower to IsBroadcastable which is further lowered.
Oct 28 2020
Thank you for the explanation. My first example was the example, so I've reworked the code to move data before replacing an op. I will follow up with adding an assert to help prevent other people making the same mistake as me.
Oct 21 2020
Thanks for the explanation regarding the AssumingYieldOp also. I found it strange that it was working with that before and just assumed that ops didn't need to be updated if only their inputs changed.
Let me know what you think of something like this River.
Oct 20 2020
Oct 16 2020
Oct 13 2020
Please let me know what you think of this. I think lowering away the "broadcast" logic and keeping the "cstr" logic in ShapeToStd fits with the purpose of the pass, but that is debatable.
Oct 9 2020
Oct 2 2020
Clarify the transformation of tensors to memrefs.
Leave TODOs to generalize this the rest of the way in regards to supported type conversions.
Sep 29 2020
I have reverted this change based on the comments in the fixup patch. I apologize for any difficulties this causes.
Sep 22 2020
Sep 18 2020
I'm abandoning this revision for now
Add note to explain purpose of method.
Ready for review now.
Update test case to pass by using previously unused value.
Note that this is not complete and was uploaded at the current state to share a patch to reproduce a bug.
Sep 15 2020
Jul 29 2020
Jul 27 2020
Correct loop space of the second for loop to be a suffix rather than a prefix.
Jul 21 2020
Jul 17 2020
Jul 15 2020
LGTM otherwise
Jul 7 2020
Refactor code. No new behavior was added.