Displaying 4 results from an estimated 4 matches for "lhs_alloca".
Did you mean:
rhs_alloca
2013 Jan 15
2
[LLVMdev] [cfe-dev] no-alias generated as result of restrict function arguments
...Ps and determine the object types.
+ LHSPtr = LHSPtr->stripInBoundsOffsets();
+ RHSPtr = RHSPtr->stripInBoundsOffsets();
+ // For allocas and arguments, remember the function they belong to.
+ const Function *lhs_func = 0;
+ const Function *rhs_func = 0;
+
+ bool lhs_alloca = isa<AllocaInst>(LHSPtr);
+ bool rhs_alloca = isa<AllocaInst>(RHSPtr);
+ bool lhs_global = isa<GlobalValue>(LHSPtr);
+ bool rhs_global = isa<GlobalValue>(RHSPtr);
+
+ bool lhs_noaliasarg = false;
+ bool rhs_noaliasarg = false;
+ bool lhs_byvala...
2013 Jan 16
0
[LLVMdev] [cfe-dev] no-alias generated as result of restrict function arguments
...tr)) {
- // If both sides are different identified objects, they aren't equal
- // unless they're null.
- if (LHSPtr != RHSPtr && llvm::isIdentifiedObject(RHSPtr) &&
- Pred == CmpInst::ICMP_EQ)
- return ConstantInt::get(ITy, false);
+ bool lhs_alloca = isa<AllocaInst>(LHSPtr);
+ bool rhs_alloca = isa<AllocaInst>(RHSPtr);
+ bool lhs_global = isa<GlobalValue>(LHSPtr);
+ bool rhs_global = isa<GlobalValue>(RHSPtr);
- // A local identified object (alloca or noalias call) can't equal any
- // inc...
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