search for: registercoalesc

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 ho...

...t_fail () from /lib64/libc.so.6 #4  0x000000000094760b in llvm::SmallVectorTemplateCommon<int, void>::operator[] (this=0x7fffffffd268, idx=0) at /home/vlj/llvm/include/llvm/ADT/SmallVector.h:143 #5  0x00000000010c8e83 in (anonymous namespace)::JoinVals::getAssignments (this=0x7fffffffd230) at RegisterCoalescer.cpp:1305 #6  0x00000000010cb459 in (anonymous namespace)::RegisterCoalescer::joinVirtRegs (this=0x21b62b0, CP=...) at RegisterCoalescer.cpp:1861 #7  0x00000000010cb646 in (anonymous namespace)::RegisterCoalescer::joinIntervals (this=0x21b62b0, CP=...) at RegisterCoalescer.cpp:1883 #8  0x000000000...

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 +++ b/lib/CodeGen/RegisterCoalescer.cpp @@ -1302,7 +1302,7 @@ public: SmallVectorImpl<unsign...

...iveInterval &b) { + // A naive test + return(a.overlaps(b)); + }; + }; +} + +#endif Property changes on: llvm/include/llvm/CodeGen/RegisterAllocator.h ___________________________________________________________________ Name: svn:eol-style + LF Index: llvm/include/llvm/CodeGen/RegisterCoalescer.h =================================================================== --- llvm/include/llvm/CodeGen/RegisterCoalescer.h (revision 0) +++ llvm/include/llvm/CodeGen/RegisterCoalescer.h (revision 0) @@ -0,0 +1,58 @@ +//===-- RegisterCoalescer.h - Register Coalescing Interface ------*- C++ -*-===// +...

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

...2012, at 3:47 PM, Andrew Clinton wrote: > 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 create that triggers this behavior. > > Any idea what might be going wrong? Are there known issues with strong PHI elimination? > > Andrew > <log_debug_co...

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 create that triggers this behavior. Any idea what might be going wrong? Are there known issues with strong PHI elimination? Andrew -------------- next part -------------...

...t 3:47 PM, Andrew Clinton wrote: > >> 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 create that triggers this behavior. >> >> Any idea what might be going wrong? Are there known issues with strong PHI elimination? >> >> Andrew >&gt...

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

...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 "-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 need...

...t curious how large the generated version will be. :-) /Patrik Hägglund -----Original Message----- From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] Sent: den 19 januari 2012 16:46 To: Patrik Hägglund H Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Problem with cross class joins in the RegisterCoalescer 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...

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

...e > irrespective of alias analysis group. However explicitly requiring an > analysis pass defeats the purpose of analysis group. Right.. At the moment I'm trying to do what Chris suggested and provide a cl::opt for coalescers. I've got about this far: llvm::cl::opt< llvm::RegisterCoalescer::Ctor, false, SomeParserToBeDefined > Coalescer("coalescer", cl::init(/* Default analysis group constructor */), cl::desc("Pick a coalescer: (default = fill this in)")); I can't use RegisterPassParser because it exp...

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

...is about a dozen lines long and refers to maybe five hundred lines of library code. All times are in milliseconds, and the total includes both compilation and program execution. llvm-3.1: 2722 total 2342 llvm::ExecutionEngine::runFunctionAsMain 1144 SelectionDAGIsel::runOnMachineFunction 294 RegisterCoalescer::runOnMachineFunction 116 RAGreedy::runOnMachineFunction llvm-3.3: 53683 total 52661 llvm::ExecutionEngine::runFunctionAsMain 16955 RAGreedy::runOnMachineFunction 15149 RegisterCoalescer::runOnMachineFunction 15072 SelectionDAGIsel::runOnMachineFunction Both cases use createJIT with default...

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