search for: calltarget

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 llv...

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", > [(XCoreBranchLink immU20:$target)]>; > > def : Pat<(XCoreBranchLink tglobaladdr:$addr), (BL_lu10 > tglobaladdr:$addr)>; > def : Pat<(XCoreBranchLink texternalsym:$addr), (BL_lu10...

.../llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > 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", [(XCoreBranchLink immU20:$target)]>; def : Pat<(XCoreBranchLink tglobaladdr:$addr), (BL_lu10 tglobaladdr:$addr)>; def : Pat<(XCoreBranchLink texternalsym:$addr), (BL_lu10 texternalsym:$addr)>; is...

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

...ality and the tight > integration with wonderful DSA. I committed a utility pass I use in a few out of tree projects. It gives very simple access to the function lists computed by DSA for indirect call sites. I've used it in several places where I needed indirect call information. See CallTarget.cpp in the DSA directory. Andrew

...try in SparcInstrInfo.td: let Uses = [O0, O1, O2, O3, O4, O5], hasDelaySlot = 1, isCall = 1, Defs = [O0, O1, O2, O3, O4, O5, O7, G1, G2, G3, G4, G5, G6, G7, D0, D1, D2, D3, D4, D5, D6, D7, D8, D9, D10, D11, D12, D13, D14, D15] in { def CALL : InstSP<(outs), (ins calltarget:$dst), "call $dst", []> { bits<30> disp; let op = 1; let Inst{29-0} = disp; } The Uses=[O0,O1,O2,O3,O4,O5] is causing this crash (and similar crashes in the PQBP and Greedy allocators if I remember right). I fixed this in the...

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 Function...

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

...R216, R217, R218, R219, R220, R221, R222, R223, R224, R225, R226, R227, R228, R229, R230, R231, R232, R233, R234, R235, R236, R237, R238, R239, R240, R241, R242, R243, R244, R245, R246, R247, R248, R249, R250, R251, R252, R253, R254, R255 ] in { def CALL : OneInZeroOut<IL_OP_CALL, (outs), (ins calltarget:$dst), "call $dst", []>; } If I don't specify the Uses, then DeadMachineInstrElim will remove all inputs to the function call. Once I specify the uses, it no longer does this. Any idea why? Thanks, Micah -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mail...

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...

...= MachineScheduler.cpp and VLIWMachineScheduler == ScheduleDAGMI The instruction being moved is a simple call: let isCall = 1, neverHasSideEffects = 1, Defs = [D0, D1, D2, D3, D4, D5, D6, D7, R28, R31, P0, P1, P2, P3, LC0, LC1, SA0, SA1, USR] in { def CALLv3 : JInst<(outs), (ins calltarget:$dst), "call $dst", []>, Requires<[HasV3T]>; } CALLv3 <ga:@printf>, %D0<imp-def,dead>, %D1<imp-def,dead>, %D2<imp-def,dead>, %R31<imp-def>, %R0<imp-use,kill>, ... Another clue - slot renumbering just took place: *** Renumbered S...

...if (Subtarget.isMachoABI()) { I = Defs_Macho + (sizeof(Defs_Macho)/sizeof(unsigned)); } else { I = Defs_ELF + (sizeof(Defs_ELF)/sizeof(unsigned)); } return I; } }] in { // Convenient aliases for call instructions def BL : IForm<18, 0, 1, (ops calltarget:$func, variable_ops), "bl $func", BrB, []>; // See Pat patterns below. def BLA : IForm<18, 1, 1, (ops aaddr:$func, variable_ops), "bla $func", BrB, [(PPCcall (i32 imm:$func))]>; def BCTRL : XLForm_2_ext<19...