similar to: [LLVMdev] "Splitting" live values

Il 14/06/2011 18:17, Carlo Alberto Ferraris ha scritto: > Suppose I have in my CFG (among others) two basic blocks A and B, with > an edge from A to B. I need to do the following: > > * get the set S of live values across that edge > I forgot to add that it doesn't have to be exactely the set of live values: it can also be an overapproximation, i.e. S might contain also

From the fact that nobody is replying I guess there's no easy way to do what I asked. Can you just confirm then that the following is a meaningful way to do it? * D_b <- set of dominators of BB b * S_b <- set containing b and its successors (optional) * VD_b <- set of the values defined in D_b * VS_b <- set of the values with uses in S_b (optional) * LV_b

I've read that LiveValues has been removed from trunk. Did it bitrot or was simply removed because a replacement is available? If it's the former, what caused the bitrotting? If it's the latter, what's the replacement? (I've found LiveVariables but I'm not sure it can be used in a ModulePass). b.r. -- Carlo Alberto Ferraris <cafxx at strayorange.com <mailto:cafxx

LiveVariables is the optimized and tested way to get variable liveness information (it's used by register allocation). Unfortunately it requires a MachineFunction to work - so you'll either need to lower to one of the built-in targets or add your own target to acquire access to this pass. Andrew On 03/31/2011 12:28 PM, Carlo Alberto Ferraris wrote: > I've read that LiveValues

> Try building with "make VERBOSE=1", which will show you the > command-lines passed to the compiler/linker. Post the output here. there you go: > cafxx at ubuntu:~/Projects/llvm2/lib/Transforms/cgf$ make VERBOSE=1 > llvm[0]: Compiling CGFPass.cpp for Debug+Asserts build (PIC) > if g++ -I/home/cafxx/Projects/llvm2/include >

> That's a weird one. Does addr2line work? > $ addr2line -e CGF.so <address> cafxx at ubuntu:~/Projects/llvm2/Debug+Asserts/bin$ objdump -t ../lib/CGF.so | grep flatten 0000000000005622 l F .text 0000000000000aa6 _ZN12_GLOBAL__N_111CGFFunction7flattenEv 00000000000041d6 l F .text 000000000000049c _ZN12_GLOBAL__N_111CGFCallSite7flattenEv

> Looks like your shared library is not being compiled with symbols. > Did you verify that your sources are compiled with -g? I think so, this is the makefile (based on the one in the Hello pass): > LEVEL = ../../.. > LIBRARYNAME = CGF > LOADABLE_MODULE = 1 > USEDLIBS = > > ifneq ($(REQUIRES_RTTI), 1) > ifneq ($(REQUIRES_EH), 1) > EXPORTED_SYMBOL_FILE =

> Are you loading the shared library directly from the build directory, > or are you installing it first? I'm invoking it directly, I guess:./opt -load=CGF.so -cgf -debug test.S should I install it? (I have no idea about how to do it, though...) > If you run "file CGF.so" on the file you actually load, does it say it > is stripped or non-stripped? cafxx at

I'm trying to figure out how to feed a blockaddress to a switch condition AND destination (basically emulating an indirectbr via a switch; I know it's not a good approach, I'm just experimenting). Suppose I have the following: SwitchInst *s = SwitchInst::Create(...); BasicBlock *bb = ...; PtrToIntInst k = new PtrToIntInst(BlockAddress::get(bb), <TYPE>, "", s);

Nella citazione martedì 2 agosto 2011 20:02:08, Michael Ilseman ha scritto: > I'm assuming that you're talking about a situation where this can't be > determined statically in the existing LLVM IR, but you know it's true > and want to put it in (e.g. you're the one generating LLVM IR). Correct. Or, more precisely, I'd like to investigate macro compression, i.e.

Consider this IR fragment produced after -O3: > %7: > %8 = phi i8* [ blockaddress(@0, %19), %19 ], [ %12, %11 ] > %9 = phi i32 [ %20, %19 ], [ 0, %11 ] > indirectbr i8* %8, [label %4, label %19] > > %19: > %20 = add nsw i32 %9, 1 > %21 = icmp eq i32 %9, 9999 > br i1 %21, label %16, label %7 the br in %19 should be optimized to branch directly to itself rather than going

Suppose I have a bb with N predecessors and N successors. What is, in your opinion, the best way to express that the bb has (dynamically) only one successor (i.e. if coming from the i-th predecessor we will always jump to the i-th successor)? b.r., -- Carlo Alberto Ferraris <cafxx at strayorange.com <mailto:cafxx at strayorange.com>> website/blog

On Jun 24, 2011, at 10:49 AM, Carlo Alberto Ferraris wrote: > >> Try building with "make VERBOSE=1", which will show you the command-lines passed to the compiler/linker. Post the output here. > there you go: >> cafxx at ubuntu:~/Projects/llvm2/lib/Transforms/cgf$ make VERBOSE=1 >> llvm[0]: Compiling CGFPass.cpp for Debug+Asserts build (PIC) >> if g++

On Jun 24, 2011, at 10:34 AM, Carlo Alberto Ferraris wrote: > >> Looks like your shared library is not being compiled with symbols. Did you verify that your sources are compiled with -g? > I think so, this is the makefile (based on the one in the Hello pass): >> LEVEL = ../../.. >> LIBRARYNAME = CGF >> LOADABLE_MODULE = 1 >> USEDLIBS = >> >>

I'm working on a pass (both LLVM and the pass have been compiled in debug+asserts mode) but when the pass crashes in the stack trace printed by opt the names of the functions inside my pass don't appear (see frames 14-16). How can I have them displayed? > cafxx at ubuntu:~/Projects/llvm2/Debug+Asserts/bin$ clear && ./opt > -load=CGF.so -cgf -debug test.S > [...] >

On Jun 24, 2011, at 11:03 AM, Carlo Alberto Ferraris wrote: > >> Are you loading the shared library directly from the build directory, or are you installing it first? > I'm invoking it directly, I guess: ./opt -load=CGF.so -cgf -debug test.S > should I install it? (I have no idea about how to do it, though...) > >> If you run "file CGF.so" on the file

Nella citazione martedì 2 agosto 2011 22:01:13, Carlo Alberto Ferraris ha scritto: > My question is: > what is the best way to > express such relationships in LLVM IR ("best" in the sense of allowing > other optimizations to run effectively)? Bear in mind that in this > example N=2, but it may be way bigger than that. Just to clarify: I already figured out two ways to

On Jun 24, 2011, at 12:36 PM, Carlo Alberto Ferraris wrote: > >> That's a weird one. Does addr2line work? >> $ addr2line -e CGF.so <address> > cafxx at ubuntu:~/Projects/llvm2/Debug+Asserts/bin$ objdump -t ../lib/CGF.so | grep flatten > 0000000000005622 l F .text 0000000000000aa6 _ZN12_GLOBAL__N_111CGFFunction7flattenEv > 00000000000041d6 l

Il 07/07/2011 11:14, Cameron Zwarich ha scritto: > I haven't read the code in detail, but it looks like JumpThreading at > least attempts to thread across indirect branches. You can either try > to fix it or file a bug with your test case. In the source it says "If the predecessor is an indirect goto, we can't split the edge.

On Jun 24, 2011, at 10:14 AM, Carlo Alberto Ferraris wrote: > I'm working on a pass (both LLVM and the pass have been compiled in debug+asserts mode) but when the pass crashes in the stack trace printed by opt the names of the functions inside my pass don't appear (see frames 14-16). How can I have them displayed? >> cafxx at ubuntu:~/Projects/llvm2/Debug+Asserts/bin$ clear