search for: calltargets

On Thu, Sep 25, 2008 at 5:04 PM, Thomas B. Jablin <tjablin at cs.princeton.edu> wrote: > Hi, > The call target pass in the poolalloc suite yields an incorrect output for the following short test program: The DSA results are now (r56847) correct for this test case. The call is marked incomplete. Doing better is actually a pathological case in DSA which is hard to fix without

Hi, The call target pass in the poolalloc suite yields an incorrect output for the following short test program: #include <stdio.h> struct OP { void (*func)(struct OP*); }; void bar(struct OP *op); void foo(struct OP *op) { printf("Foo\n"); op->func = bar; } void bar(struct OP *op) { printf("Bar\n"); op->func = foo; } int main(int argc, char **argv)

...are/llvm --with-llvmobj=/home/petsas/software/llvm petsas at shinigami:~/software/poolalloc$ make but I'm getting get this error: make[1]: Entering directory `/home/petsas/software/poolalloc/lib' make[2]: Entering directory `/home/petsas/software/poolalloc/lib/DSA' llvm[2]: Compiling CallTargets.cpp for Debug+Asserts build (PIC) CallTargets.cpp:35:3: error: use of undeclared identifier 'DEBUG_TYPE' STATISTIC (DirCall, "Number of direct calls"); ^ /home/petsas/software/llvm/include/llvm/ADT/Statistic.h:165:38: note: expanded from macro 'STATISTIC' static llvm...

On 25/07/12 12:14, Paul Shortis wrote: > Thanks Richard, > > You're correct, they are similar. In the XCoreInstrInfo.td patterns > what I'm struggling with is why this .... > > def BL_lu10 : _FLU10< > (outs), > (ins calltarget:$target, variable_ops), > "bl $target", >

On 25/07/12 18:21, Richard Osborne wrote: > On 25 Jul 2012, at 04:49, Paul Shortis wrote: > > >> Hello, >> >> I'm considering creating an LLVM backend for a 16 bit processor and >> modelling it around the (experimental) MSP430 back end. >> >> When reviewing MSP430InstrInfo.td I see >> >> def MSP430Wrapper :

HI guys. I'm trying to build the poolalloc on llvm-2.0 but there exist some errors. Can you tell me which version of llvm is known to make the poolalloc build and install successful? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070710/4ab5e155/attachment.html>

Hi Micah, the register use list gets dropped by the instruction selector because you didn't specify "variable_ops" in the input operand list of your CALL instruction. It has to look like this: (ins calltarget:$dst, variable_ops) Regards, Christoph

On Wed, 2006-05-24 at 11:04, Nai Xia wrote: > Indirect call information could be constructed either from partial result > of DSA as suggested by Andrew. And alternatively, it can use the alias > information constructed by any AA. I think both interface may be > provided to let clients chose between the generality and the tight > integration with wonderful DSA. I

On Jan 7, 2011, at 2:36 PM, Venkatraman Govindaraju wrote: > When I run LLC with option "-O0 -march=sparc" on following testcase, > fast register allocator crashes with "UNREACHABLE executed" error. LLC > generates code successfully with other standard register allocators > available. I haven't investigated the Sparc backend specifically but... My guess is

Hi I see when LLVM builds the CallGraph SCCs. a function calling through a function pointer is conservatively assumed to call internal and external functions. Therefore, it has an edges pointing to the externalnode2, ie. the externalnode representing outgoing calls from this module. does LLVM have any function pointer analysis capabilities in the mainline ? Thanks, -Trent

On Mon, Apr 28, 2014 at 10:30 PM, John Criswell <criswell at illinois.edu>wrote: > Dear Petsas, > > For analyzing indirect function calls, your best bet is probably to use > the CallGraph analysis pass that is part of DSA. DSA is included in the > poolalloc code; you can get directions on downloading poolalloc from the > SVA web page:

Hello, When I run LLC with option "-O0 -march=sparc" on following testcase, fast register allocator crashes with "UNREACHABLE executed" error. LLC generates code successfully with other standard register allocators available. $ cat call.ll define void @test() nounwind { entry: %0 = tail call i32 (...)* @foo() nounwind tail call void (...)* @bar() nounwind ret void }

...me to access this information? Should I run the passes manually, or is there another, more pass-scheduler-friendly approach? > > I would write a ModulePass that simply iterates over the call graph. LLVM provides a CallGraph analysis which one can use to find SCCs; DSA has an analysis called CallTargets which does "real" CallGraph analysis (which means that it tries to reason about function pointers, though I cannot guarantee that its reasoning will be as accurate as you want). > > If you use a ModulePass, can you analyze any part of the program you like, and you can use FunctionP...

Hi all, I have one analysis pass that I want to perform on call graph SCCs. However, for each function in the SCC, I need function-level analyses, like the dominator tree and the memory dependency analysis. I’ve been told before <http://stackoverflow.com/questions/30059622/using-dominatortreewrapperpass-in-callgraphsccpass> that these were not available from a CallGraphSCCPass. What would

Hi, In response to Chris's suggestion to construct a more precise callgraph builder. I express my personal thinking here on possible refinement. Any advice is welcome. 1. Basic data structure changes. Current callgraph builder maintains two null nodes, expressing the meaning of "anything calls !internal linkage functions" and "functions not defined in this unit call

Thanks Cristoph, I have that code in my backend, but unless I do the following, the registers are never considered 'live' into the call. / Handle a function call let isCall = 1, Defs = [ R0, R1, R2, R3, R4, R5, R6, R7, R8, R9, R10, R11, R12, R13, R14, R15, R16, R17, R18, R19, R20, R21, R22, R23, R24, R25, R26, R27, R28, R29, R30, R31, R32, R33, R34, R35, R36, R37, R38, R39, R40, R41,

Hi Micah, > In X86InstrInfo.td for Call Instructions, it mentions that Uses for > argument registers are added manually. Can someone point me to the > location where they are added as the comment doesn't reference a > where or how? the register uses are added by the function X86TargetLowering::LowerCall() during the DAG Lowering phase. This is the relevant code segment: // Add

...s information? Should I run the passes manually, or is there another, more pass-scheduler-friendly approach? >>> >>> I would write a ModulePass that simply iterates over the call graph. LLVM provides a CallGraph analysis which one can use to find SCCs; DSA has an analysis called CallTargets which does "real" CallGraph analysis (which means that it tries to reason about function pointers, though I cannot guarantee that its reasoning will be as accurate as you want). >>> >>> If you use a ModulePass, can you analyze any part of the program you like, and you c...

Andy, Jacob, I have ported Hexagon MI scheduler to use the new scheduler infrastructure, but one of my tests triggers an assert in LiveInterval update. On the surface it does not make much sense to me, so I wonder if this is something you readily recognize, before I try to prop it open... The assert is: lib/CodeGen/LiveInterval.cpp:266: llvm::LiveRange*

Hi Chris, Chris Lattner wrote: >> 2) Line 369 of PPCInstrInfo.td, we declare the non-callee saved registers. >> However, Linux and Darwin do not have the same set >> of non-callee saved registers. I don't know how to make the if(isDarwin) test >> in here >> > > Take a look at ARM/ARMRegisterInfo.td for an example of this I tried to define Defs just