Hi, Is it intentional that LazyValueInfo.getPredicateAt doesn't solve for the value and only takes assumptions into account? getPredicateAt gets lattice value from cache using getValueAt call: LVILatticeVal LazyValueInfoCache::getValueAt(Value *V, Instruction *CxtI) { ... LVILatticeVal Result; mergeAssumeBlockValueConstantRange(V, Result, CxtI); ... return Result; } Other get functions in LazyValueInfoCache solve to obtain the result: LVILatticeVal LazyValueInfoCache::getValueInBlock(Value *V, BasicBlock *BB, Instruction *CxtI) { ... pushBlockValue(std::make_pair(BB, V)); solve(); LVILatticeVal Result = getBlockValue(V, BB); mergeAssumeBlockValueConstantRange(V, Result, CxtI); ... return Result; } Thanks, Artur
----- Original Message -----> From: "Artur Pilipenko" <apilipenko at azulsystems.com> > To: llvmdev at cs.uiuc.edu > Sent: Thursday, April 16, 2015 7:22:03 AM > Subject: [LLVMdev] LazyValueInfo.getPredicateAt > > Hi, > > Is it intentional that LazyValueInfo.getPredicateAt doesn't solve for > the value and only takes assumptions into account?Yes. That function is used from only one place in JumpThreading: } else if (CondBr && CondConst && CondBr->isConditional()) { // There might be an invariant in the same block with the conditional // that can determine the predicate. LazyValueInfo::Tristate Ret LVI->getPredicateAt(CondCmp->getPredicate(), CondCmp->getOperand(0), CondConst, CondCmp); if (Ret != LazyValueInfo::Unknown) { ... and handles a situation that can only happen with @llvm.assume (where new information regarding a value's range is introduced in the block containing the conditional; normally this can only happen on edges and is picked up by getValueOnEdge, etc.) Why do you ask? -Hal> > getPredicateAt gets lattice value from cache using getValueAt call: > LVILatticeVal LazyValueInfoCache::getValueAt(Value *V, Instruction > *CxtI) { > ... > LVILatticeVal Result; > mergeAssumeBlockValueConstantRange(V, Result, CxtI); > ... > return Result; > } > > Other get functions in LazyValueInfoCache solve to obtain the result: > LVILatticeVal LazyValueInfoCache::getValueInBlock(Value *V, > BasicBlock *BB, > Instruction *CxtI) > { > > ... > pushBlockValue(std::make_pair(BB, V)); > solve(); > LVILatticeVal Result = getBlockValue(V, BB); > mergeAssumeBlockValueConstantRange(V, Result, CxtI); > ... > return Result; > } > > Thanks, > Artur > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
Hi,> Apr 16, 2015, в 9:27 PM, "Hal Finkel" <hfinkel at anl.gov> написал(а): > > ----- Original Message ----- >> From: "Artur Pilipenko" <apilipenko at azulsystems.com> >> To: llvmdev at cs.uiuc.edu >> Sent: Thursday, April 16, 2015 7:22:03 AM >> Subject: [LLVMdev] LazyValueInfo.getPredicateAt >> >> Hi, >> >> Is it intentional that LazyValueInfo.getPredicateAt doesn't solve for >> the value and only takes assumptions into account? > > Yes. That function is used from only one place in JumpThreading: > > } else if (CondBr && CondConst && CondBr->isConditional()) { > // There might be an invariant in the same block with the conditional > // that can determine the predicate. > > LazyValueInfo::Tristate Ret > LVI->getPredicateAt(CondCmp->getPredicate(), CondCmp->getOperand(0), > CondConst, CondCmp); > if (Ret != LazyValueInfo::Unknown) { > ... > > and handles a situation that can only happen with @llvm.assume (where new information regarding a value's range is introduced in the block containing the conditional; normally this can only happen on edges and is picked up by getValueOnEdge, etc.) > > Why do you ask?I'm working on exploiting dereferenceable_or_null attribute in LICM pass. For values marked with this attribute I need to know if they are known-non-null at some point (e.g. there is a null check dominating this point). One way to do this is to use LVI. Artur> > -Hal > >> >> getPredicateAt gets lattice value from cache using getValueAt call: >> LVILatticeVal LazyValueInfoCache::getValueAt(Value *V, Instruction >> *CxtI) { >> ... >> LVILatticeVal Result; >> mergeAssumeBlockValueConstantRange(V, Result, CxtI); >> ... >> return Result; >> } >> >> Other get functions in LazyValueInfoCache solve to obtain the result: >> LVILatticeVal LazyValueInfoCache::getValueInBlock(Value *V, >> BasicBlock *BB, >> Instruction *CxtI) >> { >> >> ... >> pushBlockValue(std::make_pair(BB, V)); >> solve(); >> LVILatticeVal Result = getBlockValue(V, BB); >> mergeAssumeBlockValueConstantRange(V, Result, CxtI); >> ... >> return Result; >> } >> >> Thanks, >> Artur >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory
On 04/16/2015 10:27 AM, Hal Finkel wrote:> ----- Original Message ----- >> From: "Artur Pilipenko" <apilipenko at azulsystems.com> >> To: llvmdev at cs.uiuc.edu >> Sent: Thursday, April 16, 2015 7:22:03 AM >> Subject: [LLVMdev] LazyValueInfo.getPredicateAt >> >> Hi, >> >> Is it intentional that LazyValueInfo.getPredicateAt doesn't solve for >> the value and only takes assumptions into account? > Yes. That function is used from only one place in JumpThreading: > > } else if (CondBr && CondConst && CondBr->isConditional()) { > // There might be an invariant in the same block with the conditional > // that can determine the predicate. > > LazyValueInfo::Tristate Ret > LVI->getPredicateAt(CondCmp->getPredicate(), CondCmp->getOperand(0), > CondConst, CondCmp); > if (Ret != LazyValueInfo::Unknown) { > ... > > and handles a situation that can only happen with @llvm.assume (where new information regarding a value's range is introduced in the block containing the conditional; normally this can only happen on edges and is picked up by getValueOnEdge, etc.)Hal, independent of Artur's question, I was a bit confused by the code you mention in your response. Reading through the code in JumpThreading, it seems like this case could catch any case where LVI was able to extract information about the range of a value used in a conditional branch. Looking at the surrounding code, we even seem to be checking for exactly that just above. Is there a reason why the edge sensative reasoning in the previous if block shouldn't just be sunk into LVI::getPredicateAt? Philip