similar to: [LLVMdev] Running a pass

Hello, I have a transform that, given a function F, will produce a new function G such that the basic blocks of G are (copies of) a subset of the basic blocks of F, and such that control flow is connected as you would expect. Given DominatorTree and DominanceFrontier of F, I would also like to efficiently compute DominatorTrees and DominanceFrontiers of G. I understand how to do this

On Tue, 4 Jul 2006, Fernando Magno Quintao Pereira wrote: > However, it does not remove all the critical edges. I am getting a very > weird dataflow graph (even without the Break Critical edges pass). The > dataflow generated by MachineFunction::dump() for the program below is > given here: > http://compilers.cs.ucla.edu/fernando/projects/soc/images/loop_no_crit2.pdf ... > The

Hi, Today I managed to link ioquake3, but generating a binary does not work yet. 1) On OSX, I get: Error: Code generator does not support intrinsic function 'llvm.ppc.altivec.lvsl'! when I do: llc file.bc -march=c -o file.c 2) On Linux X86, llc does not give any problem, but I get this while compiling the generated .c file: error: unknown register name 'S' in

In the instructions for writing LLVM passes, it says "[c]urrently it is illegal for a ModulePass to require a FunctionPass. This is because there is only one instance of the FunctionPass object ever created, thus nowhere to store information for all of the functions in the program at the same time." I'm a little confused by that. It was my understanding that if pass X required

Dear all, while trying to build llvm with shared libraries using GCC (tested both in Ubuntu 14.04 and Ubuntu 16.04) as in cmake -G Ninja -DBUILD_SHARED_LIBS=ON I run into the following link error lib/Transforms/IPO/CMakeFiles/LLVMipo.dir/PartialInlining.cpp.o: In function `llvm::ForwardDominanceFrontierBase<llvm::BasicBlock>::ForwardDominanceFrontierBase()':

Hi Guys, I saw in the API that DominanceFrontier has been deprecated. Is this for real? I have read the computational issues but shouldn't that be left to the users of llvm? My concern is I am writing a Control Dependence module that uses Dominance-Frontier information. Getting rid of Dominance Frontiers will put me in a tight spot. George -------------- next part -------------- An HTML

On Fri, 22 Sep 2006, Ryan M. Lefever wrote: > In the instructions for writing LLVM passes, it says "[c]urrently it is > illegal for a ModulePass to require a FunctionPass. This is because > there is only one instance of the FunctionPass object ever created, thus > nowhere to store information for all of the functions in the program at > the same time." Right. >

So, am I correct that the implication of what you're saying is that if pass X requires pass Y, then pass Y does not necessarily run to completion on every component of a program, before pass X runs. Furthermore, if those passes X and Y are both function passes, then when pass X runs on function F, the last function Y will have run on is function F. Chris Lattner wrote: > On Fri, 22

I think I misread the doxygen. verifyFunction & verifyModule return false if no errors are detected. However, my question now becomes why does the code produced by my transform pass verification, but it causes an assertion failure in the byte reader when it (the code produced by my transform) is passed to another invocation of opt? Ryan M. Lefever wrote: > I also tried iterating

Hi George, > I saw in the API that DominanceFrontier has been deprecated. Is this for real? > I have read the computational issues but shouldn't that be left to the users of > llvm? > My concern is I am writing a Control Dependence module that uses > Dominance-Frontier information. > Getting rid of Dominance Frontiers will put me in a tight spot. if the dominancefrontier

Reading the comments in Analysis/DominanceFrontier.h, I see a note that the structure is deprecated and we're not to use it for anything new. Has it been replaced with something equally useful, or shall I redo the calculation for myself, or ...? Thanks, Preston -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, A number of transforms are actually independent, so here's a partial fix. I updated the dependencies in a cluster of transforms: LowerSwitch, Mem2Reg, LowerSelect, LowerAllocations, UnifyFunctionExitNodes. The patch has been tested, but not extensively. PassManager doesn't complain, and the result of a test pass that requires all these (except for LowerAllocations) together works

I also tried iterating through the functions of the module and calling verifyFunction(), which also returns false, but does not cause an abort or report anything to stderr about what caused the verification to fail. From the doxygen for verifyFunction() and verifyModule(), it seems like they both should print information to stderr if the verification fails and should abort opt if

For a machine like an FPGA with no stack, you have to ensure that you have an optimization that rewrites the alloca into either registers (such as PromoteMem2Reg) or that you rewrite the alloca by declaring a static local, and rewriting the code to use that instead of the alloca result. Mark Mendell From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Bruce Hoult via llvm-dev

Hi, I'm Ryo Ota. I'm using LLVM 3.8.1. I have a quesion about inlining function in C++ API. I'd like to inline some functions in a module in the same way as `opt -inline` command. But my C++ code didn't work what I want to do. For example, by using `opt -inline` command,`main.ll` is converted into the `inlined.ll`(`opt` command worked what I want to do) [main.ll (Not inlined)]

Ah! I didn't know about verifyFunction; it does indeed catch it, thanks! I'll leave that call in my code for all cases for the moment, should help identify problems like that. Is there a recommended way to avoid this problem when compiling a language that has an explicit and optional return statement? On Fri, Feb 5, 2010 at 5:25 PM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote:

Hi Xiu, The Verifier pass runs a PreVerifier pass, which does not honour the action argument, and will always abort on a broken module, (Line 106, lib/VMCore/Verifier.cpp) Perhaps you should file a bug against this, to allow you to not abort if you so wish. Joey On 11 June 2012 09:41, Guowei Xu <myesis at gmail.com> wrote: > Hello everyone: > > I have a little question

I am programmatically building some functions in intermediate representation, and trying to verify them, but the verifier always reports that there is a problem, and I can't see why. Minimal test case: #ifdef _MSC_VER #pragma warning(disable : 4141) #pragma warning(disable : 4530) #pragma warning(disable : 4624) #endif #include <llvm/IR/IRBuilder.h> #include <llvm/IR/Verifier.h>

Hello everyone: I have a little question about the second argument *action* of verifyFunction. In docs: *Enumerator: * *AbortProcessAction* verifyModule will print to stderr and abort() *PrintMessageAction* verifyModule will print to stderr and return true *ReturnStatusAction* verifyModule will just return true But it still abort when I pass

On Fri, Feb 5, 2010 at 11:30 AM, Russell Wallace <russell.wallace at gmail.com> wrote: > Ah! I didn't know about verifyFunction; it does indeed catch it, > thanks! I'll leave that call in my code for all cases for the moment, > should help identify problems like that. > > Is there a recommended way to avoid this problem when compiling a > language that has an