similar to: [LLVMdev] CallGraph in immutable pass

Your understanding is correct -- this is impossible. What are you really trying to do? On Jul 3, 2013 9:15 AM, "Robert Baručák" <xbaruc00 at stud.fit.vutbr.cz> wrote: > Hello, > is there any way I can access CallGraph from immutable pass via > getAnalysis? > As I understand it, this may not be possible, because immutable pass don't > have runOn method and is

On 07/03/2013 06:18 PM, Chandler Carruth wrote: > > Your understanding is correct -- this is impossible. What are you > really trying to do? > I'm working on implementation of some fancier alias analysis algorithm. I have experienced strange behavior when I registered my AA (as module pass) into AA group. Somehow I was unable to get correct DataLayout from AA interface. So I

Dear Owen, Are passes supposed to grab the LLVMContext from the Module/Function/BasicBlock passed into their runOn<Module/Function/BasicBlock> method, or is the PassManager supposed to set the pass's Context member variable automatically? I thought it was the latter, but after an SVN update of LLVM, my passes have a NULL Context, and the LLVM code looks like the passes are all setting

On Sun, Dec 16, 2012 at 7:23 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Stephen, > > > On 13/12/12 18:58, Stephen McGruer wrote: > >> I'm wondering if the documentation for LoopPass >> (http://llvm.org/docs/**WritingAnLLVMPass.html#**LoopPass<http://llvm.org/docs/WritingAnLLVMPass.html#LoopPass>) >> is misleading or >> incorrect (or

Hi Chandler, On 17/12/12 13:47, Chandler Carruth wrote: > On Sun, Dec 16, 2012 at 7:23 AM, Duncan Sands <baldrick at free.fr > <mailto:baldrick at free.fr>> wrote: > > Hi Stephen, > > > On 13/12/12 18:58, Stephen McGruer wrote: > > I'm wondering if the documentation for LoopPass >

Dear John, I think you must call (YourPassManager)->doInitialization() to set the LLVMContext object. Nicolas John Criswell wrote: > Dear Owen, > > Are passes supposed to grab the LLVMContext from the > Module/Function/BasicBlock passed into their > runOn<Module/Function/BasicBlock> method, or is the PassManager supposed > to set the pass's Context member

On Feb 25, 2010, at 5:45 PM, David A. Greene wrote: > The RegisterPass template takes care of notifying the PassManager > that the pass exists. One of the advantages of PassManager is > that it decouples pass execution from the rest of the infrastructure > so the class need not be visible to anything outside the > implementation > of the pass itself. Even though the

I’m digging through a build failure [1], and it looks like the loop idiom recognizer adds some instructions [2], and then removes them again [3]. I don’t understand why yet, but the LegacyPassManager detects that the structural hash of the function has changed, and complains that the pass didn’t correctly report that it changed the function [4] (even though materially, it didn’t). This raises a

Nyx wrote: > Hello, > > I would just like to ask if it's possible to explicitly free allocas. This > is because I need to call functions that take structs of different sizes as > input, (possibly inside of loops) and I would rather avoid a stack overflow. > No, it's not legal to free memory returned by alloca. Such memory is allocated on the stack; the code generator

That sounds rather cumbersome, is there no simpler way to get the actual size of a struct? John Criswell wrote: > > Nyx wrote: >> Hello, >> >> I would just like to ask if it's possible to explicitly free allocas. >> This >> is because I need to call functions that take structs of different sizes >> as >> input, (possibly inside of loops) and I

On Fri, Jul 17, 2020 at 10:52 PM Nikita Popov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Fri, Jul 17, 2020 at 9:30 PM Jonathan Roelofs via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> I’m digging through a build failure [1], and it looks like the loop idiom recognizer adds some instructions [2], and then removes them again [3]. I don’t understand

In the TargetData class (available from you ExecutionEngine), you have some informations available (such as StructLayout...). On Thu, Jun 18, 2009 at 5:08 PM, Nyx <mcheva at cs.mcgill.ca> wrote: > > That sounds rather cumbersome, is there no simpler way to get the actual > size > of a struct? > > > John Criswell wrote: > > > > Nyx wrote: > >>

On Fri, 18 Jun 2004, Vladimir Prus wrote: > > actually exist in the LLVM module for the function. In particular, this > > would include any functions in a code-generator specific runtime library > > and malloc/free. The X86 code generator compiles floating point modulus > > into fmod calls, and 64-bit integer div/rem into runtime library calls. > > And why isn't

Hi Stephen, On 13/12/12 18:58, Stephen McGruer wrote: > I'm wondering if the documentation for LoopPass > (http://llvm.org/docs/WritingAnLLVMPass.html#LoopPass) is misleading or > incorrect (or if I'm just missing something.) The documentation states: > > "The doFinalization method ... is called when the pass framework has finished > calling runOnLoop

I'm wondering if the documentation for LoopPass ( http://llvm.org/docs/WritingAnLLVMPass.html#LoopPass) is misleading or incorrect (or if I'm just missing something.) The documentation states: "The doFinalization method ... is called when the pass framework has finished calling runOnLoop<http://llvm.org/docs/WritingAnLLVMPass.html#runOnLoop> for every loop in the program being

Hello, I would just like to ask if it's possible to explicitly free allocas. This is because I need to call functions that take structs of different sizes as input, (possibly inside of loops) and I would rather avoid a stack overflow. If this is not possible, an alternate solution would be for me to allocate an array of bytes larger than all the struct types I may be using, and cast that

On Fri, Feb 26, 2010 at 05:22:49PM -0800, Trevor Harmon wrote: > On Feb 25, 2010, at 5:45 PM, David A. Greene wrote: > > > The RegisterPass template takes care of notifying the PassManager > > that the pass exists. One of the advantages of PassManager is > > that it decouples pass execution from the rest of the infrastructure > > so the class need not be visible to

Chris Lattner wrote: > > Second, MO_ExternalSymbol is used for storing name of external > > variable/function, right? Why it's not possible to use MO_GlobalAddress, > > where returned GlobalValue* has isExternal set to true? The > > GlobalValue::getName would return the name of the symbol. > > Using the GlobalValue is certainly the preferred way if you have it.

Dear All, Is it possible to write a llvm pass in OCaml? Is there any API such as runOnModule() in ModulePass, runOnFunction() in FunctionPass in OCaml? I have looked through the tutorial, http://llvm.org/docs/tutorial/OCamlLangImpl1.html, it looks like just a tutorial about "Implementing a language with LLVM" in Objective Caml. Thank you for your help. Best Regards, GUanhua

Hi everyone, I'm adding loop profiling to LLVM built-in profiler. I'm just wondering in a class that's not a pass, such as ProfileInfoLoader, how can I get information produced by passes such as LoopInfo and DominatorTree? In other words, ProfileInfoLoader is not a pass, so it can't call AnalysisUsage::addRequired and AnalysisUsage::getAnalysisUsage directly. Then how can it know