similar to: [LLVMdev] run function pass conditionally

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

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 Aug 31, 2011, at 10:23 AM, Carlo Alberto Ferraris wrote: > 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... Module::findUsedStructTypes. Note that this requires scanning the entire module, it is not an efficient operation. -Chris

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 mercoledì 31 agosto 2011 20:35:46, Chris Lattner ha scritto: > On Aug 31, 2011, at 10:23 AM, Carlo Alberto Ferraris wrote: >> 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... > Module::findUsedStructTypes. Note that this requires scanning the entire module, it is not an

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

I need some advice on "forwarding" arguments to a callee. Suppose I have a function F that is called at the beginning of all other functions in the module. From F I need to access (read) the arguments passed to its immediate caller. Right now I do something like boxing all arguments in the caller inside a struct and passing a pointer to the struct to F, alongside an identifier

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 =

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

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

Hi Erkki, > I want to experiment with avoiding mutable state as far as I can. At the moment > there are no mutable variables -- only immutable value types (numerics, bool, > vectors, tuples) and I've been doing everything in LLVM registers. The compiler > doesn't generate a single alloca, load or store at the moment. > > I wonder if it was maybe a bad idea to do it this

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 bug with your test case. > In the source it says "If the predecessor is an indirect goto, we

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.

Hi Carlo, rather than declaring individual stack variables int x; int y; int z; and so on, which requires you to pass each one, or a pointer to each one, to your function, declare one stack variable of struct type that holds them all: struct StackObjects { int x; int y; int z; ... }; ... struct StackObjects stack; then pass the address of stack to your

Nella citazione giovedì 18 agosto 2011 09:11:36, Carlo Alberto Ferraris ha scritto: > I need some advice on "forwarding" arguments to a callee. Suppose I have > a function F that is called at the beginning of all other functions in > the module. From F I need to access (read) the arguments passed to its > immediate caller. Right now I do something like boxing all

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 consider my patch not mature enough to be committed. I just wanted to hear what others are saying. I'm not quite sure how to exactly deal with these cascades of selects which induce a cycle via a Phi; I'd like to implement that as well. Also, I'm not sure whether InstructionSimplify.cpp is the proper place for this optimization. -- Roland ----- Original Message ----- > From:

On Fri, Apr 27, 2012 at 7:40 PM, Yabin Hu <yabin.hwu at gmail.com> wrote: > Hi LLVMers, > > The attached patch adds a new Intrinsic named "llvm.codegen" to support > embedded LLVM IR code generation. **The 'llvm.codegen' intrinsic uses > the LLVM back ends to generate code for embedded LLVM IR strings. The code > generation target can be same or

Hi all, Does PTX backend support llvm sitofp instruction? I failed to compile my llvm source when use llc -march=ptx32. The reason is that the source has a sitofp instruction. After i changed the instruction into uitofp manually, it passed. Thanks in advance, best, Yabin -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Justin, In the PTX backend, "ret" instruction at the end of a ptx_kernel function is translated to "exit" instruction. A test case named exit.ll demos this. But in the NVPTX backend, it seems that you didn't do such a translation. Why do you choose this? Is this due to the changes of the NVIDA PTX itself? Thanks, Yabin -------------- next part -------------- An HTML