search for: registercoalescing

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

...ncent >________________________________ > De : Jakob Stoklund Olesen <stoklund at 2pi.dk> >À : Vincent Lejeune <vljn at ovi.com> >Cc : "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu> >Envoyé le : Dimanche 21 octobre 2012 0h05 >Objet : Re: [LLVMdev] RegisterCoalescing pass crashes with ImplicitDef registers > > > > >On Oct 20, 2012, at 1:23 PM, Vincent Lejeune <vljn at ovi.com> wrote: > >below is an output of "llc -march=r600 -mcpu=cayman -print-before-all -debug-only=regalloc file.shader" command from llvm3.2svn. >>Th...

On Oct 20, 2012, at 1:23 PM, Vincent Lejeune <vljn at ovi.com> wrote: > below is an output of "llc -march=r600 -mcpu=cayman -print-before-all -debug-only=regalloc file.shader" command from llvm3.2svn. > The register coalescing pass crashes when joining vreg12:sel_z with vreg13 registers, because it tries to access the interval liveness of vreg13... which is undefined. >

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 +++

...+ /// which to invalidate when running the register allocator or any + /// pass that might call coalescing. + virtual void getAnalysisUsage(AnalysisUsage &AU) const {}; + }; +} + +// Because of the way .a files work, we must force the SimpleRC +// implementation to be pulled in if the RegisterCoalescing header is +// included. Otherwise we run the risk of RegisterCoalescing being +// used, but the default implementation not being linked into the tool +// that uses it. +FORCE_DEFINING_FILE_TO_BE_LINKED(RegisterCoalescer) +FORCE_DEFINING_FILE_TO_BE_LINKED(SimpleRegisterCoalescing) + +#endif Proper...

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

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

Hi all, A question for other regalloc hackers - is there any good reason why we're requiring RegisterCoalescer tranisitively in RegAllocLinearScan (via addRequiredTransitive) ? If there's no reason I'll switch it to a plain requirement (addRequired). It's not a big deal, but is a little cleaner. Cheers, Lang.

Hi Patrik, > The "-disable-cross-class-join" flag prevents this problem from > happening but I'm afraid it will also prevent other (non-problematic) > cross class joins from happening so I'm hesitant to use it. > > So, should this not happen, or is the flag needed, or is this just a > sign that we have a really weird or buggy register model? Is this some recent

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

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 Jan 19, 2012, at 2:16 AM, Patrik Hägglund <patrik.h.hagglund at ericsson.com> wrote: > Is it intended that in some cases it is necessary to use > "-disable-cross-class-join" to be sure the resulting code is ok? No. > I have several cases where cross class joins are carried out that makes > the code turn out illegal, because the "new" register class is

...t expects a function pass constructor and the RegisterCoalescer interface is not a function pass. The question I have is how to get this to interact properly with analysis groups. The existing coalescer has this: // Need to register with PassManager so getAnalysis works RegisterPass<SimpleRegisterCoalescing> X("simple-register-coalescing", "Simple register coalescing to eliminate all possible register copies (default RC impl)"); // Declare that we implement the RegisterCoalescer interface RegisterAnalysisGroup<RegisterCoalescer, true/*The Default*/> V(X);...

On Aug 10, 2007, at 10:15 AM, David Greene wrote: > However, what happens when alias analysis information gets > invalidated? > Is Andersen's still "available" in the sense analysis groups use it? > > If not, it seems it would be tough to make sure Andersen's is always > used everywhere that AliasAnalysis is asked for because there are > passes > llvm

Compile times increased by roughly 20X after upgrading the Radian compiler project from LLVM 3.1 to 3.3. I am curious whether this is considered normal. If it is not, I would appreciate some help figuring out what it is about the Radian compiler's output which is causing LLVM to spend so much time compiling such small programs. I recorded these times with Apple's Xcode Instruments

Hi, Is it intended that in some cases it is necessary to use "-disable-cross-class-join" to be sure the resulting code is ok? I have several cases where cross class joins are carried out that makes the code turn out illegal, because the "new" register class is not allowed in all instructions where it is now used. For example, by joining %vreg4, %vreg7 and %vreg9 the

Hello. Could you please tell me how can I optimize with the back end (llc) the following piece of assembly code generated by llc: // NOTE: my processor accepts loops in the form of REPEAT(num_times)..END_REPEAT R0 = ... REPEAT(256) R5 = R0; // basically unnecessary reg. copy REPEAT(256) R10 = LS[R4]; R2 = LS[R5]; R4 =

On Thursday 09 August 2007 19:21, Chris Lattner wrote: > Interesting question, I don't have an answer to this. To make things more > complicated, you can have multiple instances of an analysis group and may > want different things at different times: > > -basicaa -licm -something_that_invalidates_aa -andersaa -licm -whatever Some questions about that: How does this