similar to: [LLVMdev] Multiple successors, single dynamic successor

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). If that's not the case, then see if JumpThreading will do it for you. I'm not familiar with a way to express exactly what you want to say, but are you opposed to just

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.

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

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

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.

Nella citazione giovedì 7 luglio 2011 19:41:16, John McCall ha scritto: > On Jul 7, 2011, at 4:33 AM, Carlo Alberto Ferraris wrote: >> 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

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

> 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

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);

> 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

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

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

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

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 * map each of them to another value (S->S') * replace - in B and its successors - all the uses of values in S with the mapped values (S') Does LLVM provide an easy way to do this (because I can't

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

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

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 Sun, Jul 31, 2011 at 7:36 AM, Carlo Alberto Ferraris <cafxx at strayorange.com> wrote: > 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 =

On Jun 24, 2011, at 1:12 PM, Carlo Alberto Ferraris wrote: > >> I meant on the stack trace, for your initial trace: >> >> $ addr2line -e CGF.so 0x00007f640b6a24fd > It doesn't work (it prints ??:0) I guess because it's PIC code (in the address above the blue part changes at each invocation of opt) Seems to be some issue with gdb not being able to read all of the