Displaying 4 results from an estimated 4 matches for "lhsarg".
Did you mean:
rhsarg
2013 Jan 15
2
[LLVMdev] [cfe-dev] no-alias generated as result of restrict function arguments
...case ICmpInst::ICMP_NE:
+ case ICmpInst::ICMP_UGT:
+ case ICmpInst::ICMP_SLT:
return ConstantInt::get(ITy, false);
- else if (Pred == CmpInst::ICMP_NE)
- return ConstantInt::get(ITy, true);
+ default:
+ return 0;
+ }
}
- } else if (Argument *LHSArg = dyn_cast<Argument>(LHSPtr)) {
- RHSPtr = RHSPtr->stripInBoundsOffsets();
- // An alloca can't be equal to an argument unless they come from separate
- // functions via inlining.
- if (AllocaInst *RHSInst = dyn_cast<AllocaInst>(RHSPtr)) {
- if (LHSArg->getPar...
2013 Jan 16
0
[LLVMdev] [cfe-dev] no-alias generated as result of restrict function arguments
...right.
- if (llvm::isKnownNonNull(LHSPtr) && isa<ConstantPointerNull>(RHSPtr)) {
- if (Pred == CmpInst::ICMP_EQ)
- return ConstantInt::get(ITy, false);
- else if (Pred == CmpInst::ICMP_NE)
- return ConstantInt::get(ITy, true);
- }
- } else if (Argument *LHSArg = dyn_cast<Argument>(LHSPtr)) {
- RHSPtr = RHSPtr->stripInBoundsOffsets();
- // An alloca can't be equal to an argument unless they come from separate
- // functions via inlining.
- if (AllocaInst *RHSInst = dyn_cast<AllocaInst>(RHSPtr)) {
- if (LHSArg->getPar...
2012 Dec 12
0
[LLVMdev] [cfe-dev] no-alias generated as result of restrict function arguments
On Wed, Dec 12, 2012 at 1:26 PM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Wed, Dec 12, 2012 at 11:01:01AM -0800, Dan Gohman wrote:
>> > Is that
>> > assumption violated if I explicitly cast away const and pass the result
>> > to a function with NoAlias argument?
>>
>> Not immediately, no. It means that you can't access the
2012 Dec 12
3
[LLVMdev] [cfe-dev] no-alias generated as result of restrict function arguments
On Wed, Dec 12, 2012 at 11:01:01AM -0800, Dan Gohman wrote:
> > Is that
> > assumption violated if I explicitly cast away const and pass the result
> > to a function with NoAlias argument?
>
> Not immediately, no. It means that you can't access the constant
> pointer's pointee directly within the noalias argument's scope. Access
> to that object must go