LazyValueInfo.getPredicateAt

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

From: "Artur Pilipenko" <apilipenko@azulsystems.com>
To: llvmdev@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

Hi,

Apr 16, 2015, × 9:27 PM, "Hal Finkel" <hfinkel@anl.gov> ÎÁÐÉÓÁÌ(Á):

From: "Artur Pilipenko" <apilipenko@azulsystems.com>
To: llvmdev@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

From: "Artur Pilipenko" <apilipenko@azulsystems.com>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: llvmdev@cs.uiuc.edu
Sent: Thursday, April 16, 2015 1:19:49 PM
Subject: Re: [LLVMdev] LazyValueInfo.getPredicateAt

Hi,

> Apr 16, 2015, в 9:27 PM, "Hal Finkel" <hfinkel@anl.gov> написал(а):
>
>> From: "Artur Pilipenko" <apilipenko@azulsystems.com>
>> To: llvmdev@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.

Ah, okay. If we have a use case, I'm fine with extending it to trigger a lattice calculation there too.

-Hal

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

From: "Philip Reames" <listmail@philipreames.com>
To: "Hal Finkel" <hfinkel@anl.gov>, "Artur Pilipenko" <apilipenko@azulsystems.com>
Cc: llvmdev@cs.uiuc.edu
Sent: Thursday, April 16, 2015 8:46:23 PM
Subject: Re: [LLVMdev] LazyValueInfo.getPredicateAt

>> From: "Artur Pilipenko" <apilipenko@azulsystems.com>
>> To: llvmdev@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?

Yea, we probably could. getPredicateAt could, if the value being queried and the context instruction have different parents, look for edge ranges from the lattice.

-Hal