similar to: [LLVMdev] Regarding LLVM Compiler

Hello, I have 2 navigations ( mainnav and subnav ) with 2 lists List have same names ( li0 li1 li2 ) What is the best way to select li1 of subnav with prototype 1.4 in this case ? I just want to hide/show it Thanks <div id="mainnav"> <ul> <li name="li0"><li name="li1"><li name="li2"> </ul> </div> <div

Hello, I am trying to write a new ModulePass using LoopInfo analysis result, but it seems I misunderstand some concept about PassManager. Basically I want to keep LoopInfo analysis result alive. Here is an example showing the problem I encountered, assuming I already addRequired<llvm::LoopInfo>() in getAnalysisUsage: void foo(llvm::Function *F1, llvm::Function *F2) { llvm::LoopInfo

Hi again, 2009/1/13 Evan Cheng <evan.cheng at apple.com>: > > > On Jan 13, 2009, at 12:27 AM, Roman Levenstein <romix.llvm at googlemail.com> > wrote: > >> 2009/1/13 Evan Cheng <echeng at apple.com>: >>> >>> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: >>> >>>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:

On 3/9/12 4:10 PM, Fan Long wrote: > Hello, > I am trying to write a new ModulePass using LoopInfo analysis result, but it seems I misunderstand some concept about PassManager. Basically I want to keep LoopInfo analysis result alive. Here is an example showing the problem I encountered, assuming I already addRequired<llvm::LoopInfo>() in getAnalysisUsage: > > void

On Feb 20, 2008, at 7:36 PM, David A. Greene wrote: > On Wednesday 20 February 2008 07:00:28 pm Evan Cheng wrote: > >>> In other words, after coalescing, should it be the case that >>> subregister >>> intervals contain at least all of the range information that was >>> contained >>> in any eliminated intervals when those eliminated intervals were

On Thursday 21 February 2008 01:23, Evan Cheng wrote: > > Also, LiveIntervalAnalysis doesn't do any subregister checks as > > far as I can tell. It's certainly not the case that subregister > > intervals contain all of the information their supperregister's > > interval contains. > > SimpleRegisterCoalescing::JoinIntervals(). When coalescing a physical

I have modified the code as follows; now i am using both scopdetection and scopinformation before dependency check but i think link is missing... virtual bool runOnFunction(Function &F) { std::unique_ptr<ScopInfo> Result; std::unique_ptr<ScopDetection> Result2; //polly::ScopDetection pl; auto &LI = getAnalysis<LoopInfoWrapperPass>().getLoopInfo(); auto

On 3/9/12 4:28 PM, Fan Long wrote: > Thank you for your quick reply. > > Actually I am using a std::map to map Function* to LoopInfo*, but that > does not help in this case. Each time I call > getAnalysis<llvm::LoopInfo>(*F), it returns the same instance of > llvm::LoopInfo, so the std::map is just mapping every function into > the same instance. It seems only the

Thank you for your quick reply. Actually I am using a std::map to map Function* to LoopInfo*, but that does not help in this case. Each time I call getAnalysis<llvm::LoopInfo>(*F), it returns the same instance of llvm::LoopInfo, so the std::map is just mapping every function into the same instance. It seems only the analysis result for the last function is valid, because all the result for

HI Hameeza, what do mean by link is still missing? Currently it is not possible to use polyhedral information from within in-tree LLVM passes. This is because Polly is not currently part of the LLVM tree, and is only linked into the tools as an external project. I.e., you can't depend on Polly passes in an in-tree pass. What you can do, though, is use Polly from an out-of-tree context. If

Thank You. Actually i pass polly canonaclize IR to my new created polly pass called "mypass". Mypass should first detect scops then find depedndencies as the mechanism conventional approach. Now i know how to write llvm pass here i am writing pass as loadable module first afterwards i will integrate it with opt in the end. I tried writing following code. Could you please help me on

On Monday 16 July 2007 18:20, Evan Cheng wrote: > > Does the current implementation follow a published algorithm? If > > so, do we > > have a pointer to it? The comments are rather sparse and it's > > difficult to > > figure out what's going on at times. > > I don't know. I suspect not. I agree the current implementation is a > bit of a

On Jul 17, 2007, at 9:28 AM, David Greene wrote: > > [...] > 00369 // If the intervals were swapped by Join, swap them back so > that the > register > 00370 // mapping (in the r2i map) is correct. > 00371 if (Swapped) SrcInt.swap(DstInt); > > Whoops! At this point repSrcReg is not consistent with SrcInt and the > same goes for repDstReg! > > 00372

Hi, I am writing an alias profiler using the points-to relation. For this I'm inserting a function call of external function with the following type profile(int,int,int,void*,void*,...) I'm trying to pass the dereferenced pointer's memory address and the address of the location who are in alias set of the pointer. For this i'm using BitCastInst BitCastInst *init1= new

On Wednesday 11 July 2007 15:07, Christopher Lamb wrote: > Could it be possible for there to be a harness type interface that > would allow coalescers that support both modes to be hooked into the > pass registration, and those that depend on the allocator not be > registered as passes? I have a patch for this kind of thing attached. Please take a look and let me know if it looks

On Sun, 2010-01-31 at 13:28 +1100, Lang Hames wrote: > Hi Sebastian, > > It boils down to this: The previous heuristic solver could return > infinite cost solutions in some rare cases (despite finite-cost > solutions existing). The new solver is still heuristic, but it should > always return a finite cost solution if one exists. It does this by > avoiding early reduction of

Hello, I need to analyze dependencies in my llvm ir by using polly. i created a new pass called mypass there i added polly dependency analysis pass but when i execute this pass in gdb i get no data. Why is that so? My code is follows; namespace { struct mypass : public FunctionPass { static char ID; mypass() : FunctionPass(ID) { } virtual bool runOnFunction(Function &F) {

On Jan 13, 2009, at 12:27 AM, Roman Levenstein <romix.llvm at googlemail.com > wrote: > 2009/1/13 Evan Cheng <echeng at apple.com>: >> >> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: >> >>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: >>> Predecessors according to CFG: 0x8fdac90 (#0) >>> %R0<def> = MOVi 0, 14, %reg0,

Hi Sebastian, It boils down to this: The previous heuristic solver could return infinite cost solutions in some rare cases (despite finite-cost solutions existing). The new solver is still heuristic, but it should always return a finite cost solution if one exists. It does this by avoiding early reduction of infinite spill cost nodes via R1 or R2. To illustrate why the early reductions can be a

2009/1/13 Evan Cheng <echeng at apple.com>: > > On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: > >> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: >> Predecessors according to CFG: 0x8fdac90 (#0) >> %R0<def> = MOVi 0, 14, %reg0, %reg0 >> *** STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4) >> [0x8fc2d68 + 0]