search for: getresult

Thanks for the replies, Daniel and Matthijs. I added some code to generate the copy constraint, which I think (in the present form) is wrong (or at best not field sensitive): +void Andersens::visitGetResultInst(GetResultInst &GR) { + if (isa<PointerType>(GR.getType())) + { + // P1 = getresult P2 --> <Copy/P1/P2> + Constraints.push_back(Constraint(Constraint::Copy, getNodeValue(GR), + getNode(GR.getOperand(0)))); + } +} Take for example...

Hi, I was trying to run Anderson's pointer analysis using opt on a 64 bit x86 system (running Ubuntu 8.04) and it seems that the 'getresult' instruction is not currently handled. When I run the same analysis on the bitcode got by compiling (using llvm-gcc on a 32 bit machine) on a 32-bit x86 machine, it runs fine. I was trying to see if it is possible to quickly add a 'visitGetResultInst' to Andersons.cpp but could not quit...

Hi Prakash, I think this is highly related to PR2527 [1] and PR2451 [2]. I assume you are using LLVM 2.3, since current svn automatically replaces getresult with extractvalue instructions (but doesn't help for Andersen's). In either case, it seems that Andersen's currently has no ready made way to indicate a part of a first-class aggregate (or vector), which is the essence of the problem here. For aggregates in memory, the pointer to the...

Looking at the InstructionCombining.cpp code: PreservedAnalyses InstCombinePass::run(Function &F,                                        AnalysisManager<Function> &AM) {   auto &AC = AM.getResult<AssumptionAnalysis>(F);   auto &DT = AM.getResult<DominatorTreeAnalysis>(F);   auto &TLI = AM.getResult<TargetLibraryAnalysis>(F);   auto *LI = AM.getCachedResult<LoopAnalysis>(F);   // FIXME: The AliasAnalysis is not yet supported in the new pass manager Thanks,...

...all, I am trying to use LLVM's AliasAnalysis pass, but from a standalone tool that uses llvm libraries. The following is the code snippet I am currently using. PassBuilder PB; auto mod_manager = ModuleAnalysisManager { }; PB.registerModuleAnalyses(mod_manager); AAResults& AAR = mod_manager.getResult<AAManager>(*M); But the code fails at .getResult with the following error: /llvm/include/llvm/IR/PassManager.h:778: typename PassT::Result& llvm::AnalysisManager<IRUnitT, ExtraArgTs>::getResult(IRUnitT&, ExtraArgTs ...) [with PassT = llvm::AAManager; IRUnitT = llvm::Module; Ext...

...lt / All ADD instruction will have a result field, regardless of whether its result is used. I checked the source code for Instruction.h/.cpp, getOperand(int) is for obtaining the operands only. There is no dedicated method to obtain the result. {I was expecting something like Instruction->getResult().} Instruction * Inst; ... Value * Res = Inst; Is the above the right way to do the work? For an other example: <result> = [tail] call [cconv <http://llvm.org/docs/LangRef.html#callingconv>] [ret attrs <http://llvm.org/docs/LangRef.html#paramattrs>]<ty> [<fnty...

...ge Reference. > > I want to know, for all LLVM Instructions, is there an easy and consistent way > to know if the current Inst has a result field? > And if yes, what is the best way to obtain it? the instruction is the result! So everywhere you though you needed to use Instruction->getResult(), just use Instruction. Thus your question about whether there is a result field doesn't make sense. The closest thing is probably: the instruction does not have void type. Ciao, Duncan. > > E.g.: > > <result> = add<ty> <op1>,<op2> /; yiel...

...RS-PostgreSQL.c -o RS-PostgreSQL.o gcc -std=gnu99 -I/usr/local/lib64/R/include -DNDEBUG -I/usr/include -I/usr/local/include -fpic -g -O2 -c RS-pgsql-copy.c -o RS-pgsql-copy.o gcc -std=gnu99 -I/usr/local/lib64/R/include -DNDEBUG -I/usr/include -I/usr/local/include -fpic -g -O2 -c RS-pgsql-getResult.c -o RS-pgsql-getResult.o gcc -std=gnu99 -I/usr/local/lib64/R/include -DNDEBUG -I/usr/include -I/usr/local/include -fpic -g -O2 -c RS-pgsql-pqexec.c -o RS-pgsql-pqexec.o gcc -std=gnu99 -shared -L/usr/local/lib64 -o RPostgreSQL.so RS-DBI.o RS-PQescape.o RS-PostgreSQL.o RS-pgsql-copy.o RS-pgsql-...

Dear all, I would like to use the PostDominatorTree in ArgPromotion. I did not find an example of how to use function level analysis inside CallGraphSCCPass. I tried to follow an example of how to use function-level pass in a module pass, but I hit "llvm_unreachable" in PMDataManager::addLowerLevelRequiredPass. What would be a proper way to make PostDominatorTree available in

...le to get to the ModuleAnalysisManager and PSI because it may not > always through (const) FunctionAnalysisManager, > unless ModuleAnalysisManagerFunctionProxy is already cached. > > Since FunctionAnalysisManager we can get from LoopAnalysisManager is a > const ref, we cannot call getResult on it and always get > ModuleAnalysisManager and PSI (see below.) This actually happens in my > experiment. > > SomeLoopPass::run(Loop &L, LoopAnalysisManager &LAM, …) { > auto &FAM = LAM.getResult<FunctionAnalysisManagerLoopProxy>(L, > AR).getManager(); >...

...fix. In particular, now that structs are a first class values, the old way or returning multiple values is a bit confusing. The old way had a variable number of arguments to the return instruction, which could come out at the caller end as some special aggregrate value that could be indexed using getresult. Now that aggregrates are first class, you should be able to simply return a single struct and access the result in the caller using the new extractvalue instruction. However, both approaches define a function with a struct as a return type: It's not possible to tell the difference between bo...

...ew > structural problems that seem non-trivial to fix. Hi, thanks for your interest! > Furthermore, as far as I've understood, the intention is to remove the > "multiple return value" support in favour of returning structs. I > take it this > means that at least the getresult instruction will be removed, and > possible > the multiple operand return as well. This would partly solve some > issues, but > will completely remove the concept of returning multiple values > (unless you > adopt the above approach of always returning structs, even for &g...

...::LazyCallGraph::SCC &C, > llvm::CGSCCAnalysisManager &AM, > llvm::LazyCallGraph &CG, > llvm::CGSCCUpdateResult &UR) { > llvm::FunctionAnalysisManager &FAM = > AM.getResult<llvm::FunctionAnalysisManagerCGSCCProxy>(C, CG) > .getManager(); > for (llvm::LazyCallGraph::Node &N : C) { > llvm::Function &F = N.getFunction(); > llvm::PostDominatorTree &PDT = > FAM.getResult<llvm::PostDominatorTreeAnalys...

...-level and >>>> loop-level PSI and loop-level BFI, which internally >>>> act like their outer-scope versions but provide >>>> inner-scope results only. This way, we could always >>>> call getResult for PSI and BFI. However, this would >>>> still involve running an outer-scope analysis from >>>> an inner-scope pass. >>>> >>>> Caching the FAM and the MAM proxies >>>> We co...

Hi. The attached patch adds wrappers for the instructions vicmp, vfcmp, ret (multiple) and getresult, and for the vicmp and vfcmp operations on constants, to llvm-c. Also: 1) There appears to be no way to create intrinsics via llvm-c. Is there? 2) The "extractvalue"[1] and "insertvalue"[2] instructions don't seem to be addable via IRBuilder. Why? Cheers, -Mahadevan. [1...

...ached analysis results provided by the pass manager. Adding inner-scope versions of PSI and BFI We could consider adding a function-level and loop-level PSI and loop-level BFI, which internally act like their outer-scope versions but provide inner-scope results only. This way, we could always call getResult for PSI and BFI. However, this would still involve running an outer-scope analysis from an inner-scope pass. Caching the FAM and the MAM proxies We could consider caching the FunctionalAnalysisManager and the ModuleAnalysisManager proxies once early on instead of adding a new proxy. But it seems t...

Hi Dan, > Yes, the intention is that getresult will be removed once first-class > aggregates are a ready replacement. This won't leave LLVM missing the > concept of returning multiple values; a struct can be thought of as > a container for multiple values. I'm not saying we don't have some way of modeling multiple return va...

...rovided by the pass manager. > > Adding inner-scope versions of PSI and BFI > We could consider adding a function-level and loop-level PSI and > loop-level BFI, which internally act like their outer-scope versions but > provide inner-scope results only. This way, we could always call getResult > for PSI and BFI. However, this would still involve running an outer-scope > analysis from an inner-scope pass. > > Caching the FAM and the MAM proxies > We could consider caching the FunctionalAnalysisManager and the > ModuleAnalysisManager proxies once early on instead of addin...

On Jun 2, 2008, at 8:45 AM, Matthijs Kooijman wrote: > Hi Dan, > >> Yes, the intention is that getresult will be removed once first-class >> aggregates are a ready replacement. This won't leave LLVM missing the >> concept of returning multiple values; a struct can be thought of as >> a container for multiple values. > I'm not saying we don't have some way of modeling m...

Hi Philip, Thanks for the response. Under llvm-5.0.2 and llvm-6.0.1 in Debug mode, the crash hit at the same assertion: /usr/local/include/llvm/IR/PassManager.h:689: typename PassT::Result& llvm::AnalysisManager<IRUnitT, ExtraArgTs>::getResult(IRUnitT&, ExtraArgTs ...) [with PassT = llvm::InnerAnalysisManagerProxy<llvm::AnalysisManager<llvm::Loop, llvm::LoopStandardAnalysisResults&>, llvm::Function>; IRUnitT = llvm::Function; ExtraArgTs = {}; typename PassT::Result = llvm::InnerAnalysisManagerProxy<llvm::AnalysisMa...