similar to: [LLVMdev] Trasitively requiring RegisterCoalescer in RegAllocLinearScan

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 Fri Apr 02 00:37:03 +0200 2010, Trevor Harmon wrote: > On Mar 31, 2010, at 3:13 PM, Owen Anderson wrote: > > Others, like MemoryDependenceAnalysis, are "lazy." MDA > > specifically does NOT compute results in its runOnFunction(), > > instead computing results on-demand when a user queries it. Because > > MDA depends on AA, we must ensure that, as long as

Ok, I've been struggling with this for two days and hopefully someone can help me out. I have a set of passes, analysis passes A, B, C, D and transformation passes E and F. Pass C depends on pass A and pass D depends on pass B. Pass E depends on C and D and does not preserve any analysis pass. Pass F depeds on pass A and pass C. Pass F runs after pass E. Graphically the dependency graph

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 Mar 31, 2010, at 3:13 PM, Owen Anderson wrote: > Some analyses, like Andersen's AA, do all their computation in their > runOnFunction(). Therefore, anything they depended on can be > destroyed after the runOnFunction() returns. What about AA itself? Would addRequired<AliasAnalysis> keep AliasAnalysis alive (but allow AliasAnalysis's dependencies to die)? >

Hi, I'm a bit confused about the distinction between addRequired and addRequiredTransitive in AnalysisUsage. From PassAnalysisSupport.h: "REQUIRES (must be available when the pass runs), REQUIRES TRANSITIVE (must be available throughout the lifetime of the pass)." The part that's confusing me is "must be available when the pass runs". I don't see how

I am having a hard time figuring out the difference between addRequired and addRequiredTransitive. Could someone please clarify the difference? Let's say I have a function pass P1 that relies on a function pass P2. P1 computes some sort of analysis on a function F and P2 uses that analysis when it processes F. Does that mean that I should use addRequiredTransitive? Thanks, Ryan

On Mar 31, 2010, at 2:53 PM, Trevor Harmon wrote: > I'm a bit confused about the distinction between addRequired and > addRequiredTransitive in AnalysisUsage. From PassAnalysisSupport.h: > > "REQUIRES (must be available when the pass runs), REQUIRES TRANSITIVE > (must be available throughout the lifetime of the pass)." > > The part that's confusing me

I will be removing RegAllocLinearScan and VirtRegRewriter from trunk shortly after we cut the 3.0 release branch. LLVM 3.0 will still ship with the linear scan register allocator, but the default will be the new greedy allocator. Linear scan can be enabled by passing '-regalloc=linearscan -join-physregs' to llc. RegAllocLinearScan and VirtRegRewriter need to go away soon because they

Hi developers, I have some problems using a non-default alias analysis. I wrote a modulepass which needs a functionpass. The functionpass needs a type bases alias analysis instead of the basicaa. I added the command line parameter for this analysis to the opt invocation as follows: opt -tbaa -global-live-values test.bc The 'global-live-values' pass preserves all and requires a

Hello, I have a minimal testcase which crashes RegisterCoalescer in my out-of-tree target. It only crashes in Debug builds of llc---not in Release builds. Also, interesting to note that the x86 backend lowers this same testcase successfully. I did a quick search of bugs.llvm.org and found no matches. This implies that the problem is in my backend and/or how my backend interacts with

Here it is :  Starting program: /home/vlj/llvmbin/bin/llc -march=r600 -mcpu=cayman /home/vlj/shader [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". llc: /home/vlj/llvm/include/llvm/ADT/SmallVector.h:143: const T& llvm::SmallVectorTemplateCommon<T, <template-parameter-1-2> >::operator[](unsigned int) const [with T

On Jul 11, 2007, at 11:39 AM, David Greene wrote: > On Wednesday 11 July 2007 12:41, Tanya M. Lattner wrote: > >> I think the coalescer should be flexible enough to be run >> independent of >> the register allocator. For example, you may want to expose the >> copies >> induced by transforming out of SSA to the scheduler. If the >> scheduler is

On Friday 10 August 2007 13:54, Devang Patel wrote: > > Or is it sufficient than an Andersen's object is constructed and > > that that > > constitutes "availability?" > > What do you mean by "available" ? You are using quotes :) "Available" as referenced by PassSupport.h: /// RegisterAnalysisGroup - Register a Pass as a member of an

Sorry, our backend is currently based on LLVM 3.0. (We are currently in the process of rebasing.) /Patrik Hägglund -----Original Message----- From: Anton Korobeynikov [mailto:anton at korobeynikov.info] Sent: den 19 januari 2012 14:28 To: Patrik Hägglund H Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Problem with cross class joins in the RegisterCoalescer Hi Patrik, > The

I'm the person who wrote it, and it's not really maintained, as we decided we wanted to go in a different direction long-term by having fewer passes making independent coalescing decisions rather than more. At the time I stopped working on it, it worked fine on x86 but caused problems with armv7 NEON code. If you file a PR with a test case, I am happy to take a quick look and try to fix

I've started using the strong PHI elimination pass, and it seems to work beautifully (producing much better placement of copy instructions) - though I'm seeing that it triggers an assert in debug+assert builds. The assertion is on line 1388 of RegisterCoalescer.C. Attached is the -debug output from the machine optimization part of the optimizer, for the simplest test case I could

I will try to make a standalone test case but the one that is failing uses a custom back end, so it's not really portable. So is the plan to have the strong PHI elimination behavior rolled into other passes? Andrew On 06/20/2012 06:54 PM, Cameron Zwarich wrote: > I'm the person who wrote it, and it's not really maintained, as we decided we wanted to go in a different direction

Thanks! Our bug is now fixed. Our getMatchingSuperRegClass is huge (more than 300 lines), messy, and incomplete. > Or you could just rebase. On trunk, TableGen writes this difficult function for you. That in itself would be a compelling reason to get the rebase to trunk done. I just curious how large the generated version will be. :-) /Patrik Hägglund -----Original Message----- From: Jakob

On Oct 20, 2012, at 3:37 PM, Vincent Lejeune <vljn at ovi.com> wrote: > #5 0x00000000010c8e83 in (anonymous namespace)::JoinVals::getAssignments (this=0x7fffffffd230) at RegisterCoalescer.cpp:1305 Does this fix it? diff --git a/lib/CodeGen/RegisterCoalescer.cpp b/lib/CodeGen/RegisterCoalescer.cpp index ba6b456..2ca67d6 100644 --- a/lib/CodeGen/RegisterCoalescer.cpp +++