search for: functioninfo

Inline George > On Jan 26, 2015, at 1:05 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > George, given that, can you just build constexpr handling (it's not as easy as you think) as a separate funciton and have it use it in the right places? Will do. :) > FWIW, my current list of CFLAA issues is: > > 1. Unknown values (results from ptrtoint, incoming

...te that there are no aliases. I'm certain I'm missing something, but I don't know what. To be absolutely clear, a Result is calculated of type: std::unique_ptr<CFLAndersAAResult> Result; And CFLAndersAAResult contains member fields: DenseMap<const Function *, Optional<FunctionInfo>> Cache; std::forward_list<cflaa::FunctionHandle<CFLAndersAAResult>> Handles; The DenseMap Cache is empty, and so is Handles. I can do -print-alias-sets, and that prints something, but I don't think it's the result of the Andersen analysis. Because when I do commands...

George, given that, can you just build constexpr handling (it's not as easy as you think) as a separate funciton and have it use it in the right places? FWIW, my current list of CFLAA issues is: 1. Unknown values (results from ptrtoint, incoming pointers, etc) are not treated as unknown. These should be done through graph edge (so that they can be one way, otherwise, you will unify

...t; so there's nothing else to change. When I thought about this very hard, it made sense. Thanks for the insight! It sounds a bit hard to keep track of which types are based (directly or indirectly) on incomplete types, so for the time being I'm clearing the whole of the TypeCache and the FunctionInfos cache every time any type is completed. I realise this is a bit brutal. Now I'm running into another problem with the implementation: EmitCXXConstructor() and EmitCXXDestructor() don't do most of the stuff that's done for normal functions in EmitGlobalFunctionDefinition. In particular...

...// clearly ptr1 and ptr2 should not be unified into the same set, so + // we should filter out the (potentially shared) instance to + // i32* null. + return isa<Constant>(Val) && + !isa<GlobalValue>(Val) && + !isa<ConstantExpr>(Val); } static FunctionInfo buildSetsFrom(CFLAliasAnalysis &Analysis, Function *Fn) { @@ -881,7 +961,6 @@ static FunctionInfo buildSetsFrom(CFLAliasAnalysis &Analysis, Function *Fn) { }; StratifiedSetsBuilder<Value *> Builder; - SmallVector<GraphT::Node, 16> Worklist; for (auto &Pair : Ma...

----- Original Message ----- > From: "James Molloy via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Vaivaswatha Nagaraj" <vn at compilertree.com> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, December 3, 2015 4:41:46 AM > Subject: Re: [llvm-dev] Function attributes for LibFunc and its impact on GlobalsAA > >

On Thu, Jul 7, 2011 at 12:55 AM, Jay Foad <jay.foad at gmail.com> wrote: >> 1. Clang - Jay, do you have a patch for this? > > Yes. It's good enough to build most of LLVM+Clang, except for a couple > of files. But I'm running out of time and expertise to be able to fix > the remaining bits. Some specific concerns: > > 1. Many Objective-C(++) tests fail, because

...// clearly ptr1 and ptr2 should not be unified into the same set, so + // we should filter out the (potentially shared) instance to + // i32* null. + return isa<Constant>(Val) && + !isa<GlobalValue>(Val) && + !isa<ConstantExpr>(Val); +} + static FunctionInfo buildSetsFrom(CFLAliasAnalysis &Analysis, Function *Fn) { NodeMapT Map; GraphT Graph; @@ -893,7 +906,7 @@ static FunctionInfo buildSetsFrom(CFLAliasAnalysis &Analysis, Function *Fn) { while (!Worklist.empty()) { auto Node = Worklist.pop_back_val(); auto *CurValue =...

No, i mean the actual store instruction looks like "store i16 %conv22, i16* getelementptr inbounds ([16 x i16]* @pA, i64 0, i64 12), align 2, !tbaa !1" Not that the pointer operand comes from a GEP, but it is a constantexpr, whose opcode is GEP. It sucks that there is such a complex thing to be handled as a store operand directly , but such is life ... CFL-AA *should* treat this