similar to: [LLVMdev] What's a good forum for discussing compiler design?

Quick question: how do I get a list of StructType* defined/used in a Module? I can't seem to find an appropriate iterator in the Module class... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110831/17715c85/attachment.html> -------------- next part -------------- A non-text attachment was

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

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

> 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

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

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

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

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

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

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.

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

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

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

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 =

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.

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

On Jul 7, 2011, at 2:05 AM, Carlo Alberto Ferraris wrote: > 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,

On Jul 7, 2011, at 10:15 PM, Carlo Alberto Ferraris wrote: > I'll try to inspect the assembler. Just a quick thought in the mean time, in the snippet I posted, if the backedge pointed directly to %19, other optimizations would likely notice that the loop could be removed entirely and replaced with a single addition. Do you think the code generator is able t > o do this? Why would you