search for: immutablepasses

If the TargetData pass isn't registered in the global registry, getPassInfo() returns null. Now when you add a TargetData pass, it winds up in ImmutablePasses. Any search through ImmutablePasses assumes that getPassInfo() for every member returns something other than null. So findAnalysisPass for *any* analysis pass can crash the system if the TargetData pass is lurking in the list without being registered. Since we want to be able to run opt without a...

On Tue, Oct 20, 2009 at 12:50 PM, Dan Gohman <gohman at apple.com> wrote: > > On Oct 20, 2009, at 10:13 AM, Kenneth Uildriks wrote: > >> On Tue, Oct 20, 2009 at 12:08 PM, Dan Gohman <gohman at apple.com> wrote: >>> Unfortunately, yes.  See PR4542.  Progress has been made recently >>> though -- the optimizers are now ready.  The main things left to do

Hello, I am trying to add some thing into LLVM, while I encountered some problems. So my situation is that I have some information W, some transform passes may change it, after these passes, I need the new W. What I did is to create an analysis pass similar to scalar-evolution or loopinfo, I can get the information by using getAnalysis<W>(); and preserve this information W by using

...runOnSCC, I am instead getting the > > default, dummy version of my analysis, which should be overridden by > > the one that was brought in with -load. > > What sort of pass is it? The inliner is a ModulePass, so the only thing > it can getAnalysis<> are modulepasses and immutablepasses: functionpasses > won't work. My pass is a ModulePass, although it's actually just an interface to external data, so I suppose it could potentially be an ImmutablePass. I've been meaning to revisit that, but it wasn't a high priority as long as it was working. ...snip... > &...

...tting the > > > default, dummy version of my analysis, which should be overridden by > > > the one that was brought in with -load. > > > > What sort of pass is it? The inliner is a ModulePass, so the only thing > > it can getAnalysis<> are modulepasses and immutablepasses: functionpasses > > won't work. > > My pass is a ModulePass, although it's actually just an interface to > external data, so I suppose it could potentially be an ImmutablePass. > I've been meaning to revisit that, but it wasn't a high priority as > long as it wa...

On Wed, Oct 21, 2009 at 10:59 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > If the TargetData pass isn't registered in the global registry, > getPassInfo() returns null. > > Now when you add a TargetData pass, it winds up in ImmutablePasses. > Any search through ImmutablePasses assumes that getPassInfo() for > every member returns something other than null.  So findAnalysisPass > for *any* analysis pass can crash the system if the TargetData pass is > lurking in the list without being registered. > > Since we want to...

Hi, I wrote a module pass that uses Alias Analysis. For this reason I added AU.addRequired<AliasAnalysis>() to function getAnalysisUsage and used getAnalysis<AliasAnalysis>() in my pass. I tried a few types of alias analyses and I discovered that only alias analyses which are ImmutablePasses are returned using getAnalysis<AliasAnalysis>(). Moreover, when I added both ImmutablePass and FunctionPass, getAnalysis<AliasAnalysis>() returned the ImmutablePass while the FunctionPass did not even appear in the AA chain ( I assume it is because building the chain uses getAnalysis as...

Hi, I'm attempting to do some alias analysis & other memory inspection. I've written a pointless AliasAnalysis pass (that says everything must alias) to attempt to verify that my pass is getting picked up & run by opt. I run opt with: opt -load ~/Applications/llvm/lib/MustAA.so -must-aa -aa-eval -debug < trace0.ll I see my pass being initialized, but never being called (I see

Hi all, > If I read the standard correctly, the properties of these address spaces can > be fully captured by defining the relationship between every pair of address > spaces (disjoint, identical, subset/superset). > > I think it would make sense to make these relationships backend/platform > specific, but for clang and the optimization passes to properly work with > address

On Jul 25, 2008, at 16:57, John Criswell wrote: > Devang Patel wrote: > >> On Jul 25, 2008, at 12:58 PM, Marc de Kruijf wrote: >> >> I'd like to write a pass that does both: implements a code >> transformation and saves information that can be accessed by >> subsequent passes. >> >> Ideally, we want to use two separate pass. However, it is

This seems like a separate issue. On Jul 26, 2008, at 5:56 PM, Gordon Henriksen wrote: > I had a similar problem with the GC metadata information. Ultimately, > I had to structure it as an ImmutablePass (with an explicit pass to > free the contained information) because it would be invalidated by > other passes at random. If GC metadata information is not explicitly listed as

On Dec 4, 2007, at 11:24, Vikram S. Adve wrote: > Is it possible to AddRequired<...> a pass that is dynamically > loaded? This would be very convenient for a course project but the > documentation about pass interactions says nothing about dynamically > loaded passes and vice versa. > > More specifically, to refer to the pass name in AddRequired, I need > to

> > Hello, > > I'm trying to enable interprocedural register allocation (IPRA). Hi Maxime, I don't understand here why you need to enable IPRA as that is already scheduled based on option -mllvm -enable-ipra. So I think easy way to make IPRA execute every time is to set default value of EnableIPRA option to true. you can find this option defined in

I'm in a debug build with assertions turned on for llvm-2.9, and I get a segfault whenever I try to schedule one of my own immutable passes in a pass manager. It seems that one of the passes that I'm scheduling (IndVarSimplify) attempts to ask for TargetData if it's available (I'm not providing it), and that's when it segfaults. If I split that pass into it's own pass

...; from within Inliner::runOnSCC, I am instead getting the > default, dummy version of my analysis, which should be overridden by > the one that was brought in with -load. What sort of pass is it? The inliner is a ModulePass, so the only thing it can getAnalysis<> are modulepasses and immutablepasses: functionpasses won't work. > I'm having a hard time debugging this, so any tips for how to track > the problem down would be appreciated. Try passing -debug-pass=Structure to opt. > I am running on Linux, and the version of LLVM I am working with is > from CVS a couple of m...

...eth Uildriks wrote: > On Wed, Oct 21, 2009 at 10:59 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: >> If the TargetData pass isn't registered in the global registry, >> getPassInfo() returns null. >> >> Now when you add a TargetData pass, it winds up in ImmutablePasses. >> Any search through ImmutablePasses assumes that getPassInfo() for >> every member returns something other than null. So findAnalysisPass >> for *any* analysis pass can crash the system if the TargetData pass is >> lurking in the list without being registered. >>...

Hi Mon Ping, I've again attached a patch, wich lets LLVM know about about the relations between different address spaces. Instead of cramming this info in with TargetData (with all kinds of unwanted side effects, especially for the IR), I opted to create a new pass, TargetAddrspaces, which holds this information. Just like TargetData, this can be added to the passmanager by the tool running

Hello LLVMdev, I’m using LLVM to do static analysis exclusively (without any code generation). To implement this analysis, I’m using multiple address spaces to disambiguate the purpose of the pointed memory. Since address spaces never alias in my model, I set on to implement an alias analysis pass that would exactly provide this information, as I’m seeing a couple of otherwise dead store that

Hi Matthijs, Thanks for giving some code so we can discuss this in more concrete detail. In terms of the information we need, I think you have it right. We just need a description of how the different address spaces relate and I don't see much of an issue with how you implemented to InstructionCombining. As you also mentioned, I don't like that we pass a reference to

Hi Eli, Mon Ping, > In ISO/IEC WG14 n1169 on the C extensions to support embedded > processors, any two address spaces must be disjoint, must be > equivalent, or must be nested. Ah, that standard is a lot clearer on this subject than the DSP-C one I read was. > As Eli indicated, the actual relationship is platform specific depending on > what makes the most sense for