Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp | ||
---|---|---|
824 | rename getTypeSizeInBits()? Worth introducing getType(), possibly as a method of VPValue? Callers could then get its scalar size in bits if interested, although in this case the types themselves should arguably be compared rather than their scalar sizes in bits? | |
829 | Should this cast case be placed first? | |
832 | (hence getType() may be more natural.) | |
846–852 | ("if Ty is equal to the type of A" also refers to types rather than their scalar size in bits.) | |
llvm/test/Transforms/LoopVectorize/if-pred-stores.ll | ||
542 | This "removeRedundantCasts" elimination seems to catch opportunities in the original (unoptimized) code rather than opportunities generated by LV itself, as in Mul-by-1/Add-0. But that may change once bitwidth minimization takes place as VPlan2VPlan transform (D149903)? |
Rebase and address comments, thanks!
ping :)
llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp | ||
---|---|---|
824 | I think in general there we need to properly infer the types and not rely on the underlying value, see https://github.com/llvm/llvm-project/pull/69013 | |
829 | Reordered. | |
llvm/test/Transforms/LoopVectorize/if-pred-stores.ll | ||
542 | Yes, this will be enabled/used by D149903 |
llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp | ||
---|---|---|
824 | Worth a TODO to replace relying on underlying value with type analysis? Should we return and compare types rather than their sizes in bits? For RAUW types must match not only their size in bits, although we are dealing with integer types only here. As commented below: "... if Ty is equal to the type of A". | |
848 | nit: A in the comment does not match A above. Code suggested below setting A = ROp0->getOperand(0) tried to align them. Could be further aligned by doing something like: // Simplify (trunc (zext A) to Ty) -> A if Ty is equal to the type of A. VPRecipeBase *Zext = R.getOperand(0)->getDefiningRecipe(); if (!Zext || getOpcodeForRecipe(*Zext) != Instruction::ZExt) break; VPValue *A = Zext->getOperand(0); VPValue *Trunc = R.getVPSingleValue(); if (getType(Trunc) == getType(A)) Trunc->replaceAllUsesWith(A); |
Hi!
The following starts crashing with this patch:
opt -passes="loop-vectorize" bbi-88061.ll -o /dev/null
It yields
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: ../../main-github/llvm/build-all/bin/opt -passes=loop-vectorize bbi-88061.ll -o /dev/null #0 0x0000560ede4fecf7 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (../../main-github/llvm/build-all/bin/opt+0x2f49cf7) #1 0x0000560ede4fc84e llvm::sys::RunSignalHandlers() (../../main-github/llvm/build-all/bin/opt+0x2f4784e) #2 0x0000560ede4ff3bf SignalHandler(int) Signals.cpp:0:0 #3 0x00007f353ef87630 __restore_rt sigaction.c:0:0 #4 0x0000560edea0b1d4 llvm::VPlanTransforms::optimize(llvm::VPlan&, llvm::ScalarEvolution&) (../../main-github/llvm/build-all/bin/opt+0x34561d4) #5 0x0000560ede8f6ec5 llvm::LoopVectorizationPlanner::buildVPlansWithVPRecipes(llvm::ElementCount, llvm::ElementCount) (../../main-github/llvm/build-all/bin/opt+0x3341ec5) #6 0x0000560ede8f659c llvm::LoopVectorizationPlanner::plan(llvm::ElementCount, unsigned int) (../../main-github/llvm/build-all/bin/opt+0x334159c) #7 0x0000560ede9098ab llvm::LoopVectorizePass::processLoop(llvm::Loop*) (../../main-github/llvm/build-all/bin/opt+0x33548ab) #8 0x0000560ede90f5b3 llvm::LoopVectorizePass::runImpl(llvm::Function&, llvm::ScalarEvolution&, llvm::LoopInfo&, llvm::TargetTransformInfo&, llvm::DominatorTree&, llvm::BlockFrequencyInfo*, llvm::TargetLibraryInfo*, llvm::DemandedBits&, llvm::AssumptionCache&, llvm::LoopAccessInfoManager&, llvm::OptimizationRemarkEmitter&, llvm::ProfileSummaryInfo*) (../../main-github/llvm/build-all/bin/opt+0x335a5b3) #9 0x0000560ede90ff18 llvm::LoopVectorizePass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (../../main-github/llvm/build-all/bin/opt+0x335af18) #10 0x0000560ede71ce4d llvm::detail::PassModel<llvm::Function, llvm::LoopVectorizePass, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (../../main-github/llvm/build-all/bin/opt+0x3167e4d) #11 0x0000560eddf1df64 llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (../../main-github/llvm/build-all/bin/opt+0x2968f64) #12 0x0000560edc2e228d 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>&) (../../main-github/llvm/build-all/bin/opt+0xd2d28d) #13 0x0000560eddf2234e llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (../../main-github/llvm/build-all/bin/opt+0x296d34e) #14 0x0000560edc2e202d llvm::detail::PassModel<llvm::Module, llvm::ModuleToFunctionPassAdaptor, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (../../main-github/llvm/build-all/bin/opt+0xd2d02d) #15 0x0000560eddf1d0f4 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (../../main-github/llvm/build-all/bin/opt+0x29680f4) #16 0x0000560edbedfc13 llvm::runPassPipeline(llvm::StringRef, llvm::Module&, llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::StringRef, llvm::ArrayRef<llvm::PassPlugin>, llvm::opt_tool::OutputKind, llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool, bool, bool) (../../main-github/llvm/build-all/bin/opt+0x92ac13) #17 0x0000560edbeed25c main (../../main-github/llvm/build-all/bin/opt+0x93825c) #18 0x00007f353c6ba555 __libc_start_main (/lib64/libc.so.6+0x22555) #19 0x0000560edbed9db0 _start (../../main-github/llvm/build-all/bin/opt+0x924db0) Segmentation fault (core dumped)
rename getTypeSizeInBits()?
Worth introducing getType(), possibly as a method of VPValue?
Callers could then get its scalar size in bits if interested, although in this case the types themselves should arguably be compared rather than their scalar sizes in bits?