similar to: [LLVMdev] Strong PHI elimination asserts in RegisterCoalescer.C:1388

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

Hello, I am implementing a code transformation that would heavily benefit from the CodeGen/StrongPHIElimination pass, but on the two bytecode files I've tested it on so far llc segfaults on both. I see there have been no substantive changes to this code since the middle of last year. Could someone please tell me what the status of this pass is? Thank you. Marc -------------- next part

Do you mean that "normal" SSA phi elimination algorithm is DemotePHI()? Thx, Seung ---- Original message ---- >Date: Mon, 24 Mar 2008 21:43:06 -0700 >From: Chris Lattner <sabre at nondot.org> >Subject: Re: [LLVMdev] What is "strong phi elimination" >To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> >Cc: Christopher Lamb

Can you describe quickly (or point to references for the inclined) what this pass will do and what other stuff it might enable for LLVM? I'm just curious. -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080324/46829334/attachment.html>

Ask an ye shall receive. From the .cpp file: // = = =---------------------------------------------------------------------- ===// // // This pass eliminates machine instruction PHI nodes by inserting copy // instructions, using an intelligent copy-folding technique based on // dominator information. This is technique is derived from: // // Budimlic, et al. Fast copy coalescing and

On Jun 8, 2012, at 9:02 AM, Hal Finkel <hfinkel at anl.gov> wrote: > On Fri, 8 Jun 2012 08:49:32 -0700 > Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> When machine code is still in SSA form, there are restrictions on >> what can be done with physical registers, which by their nature can't >> be in SSA form. Lang and I have been trying to come up

On Fri, 08 Jun 2012 09:24:16 -0700 Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jun 8, 2012, at 9:02 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > > On Fri, 8 Jun 2012 08:49:32 -0700 > > Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > >> When machine code is still in SSA form, there are restrictions on > >> what can

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

On Jun 7, 2012, at 10:54 PM, Hal Finkel wrote: > For example, sometimes LiveIntervals asserts with: > register: > %CTR8 > clang: /llvm-trunk/lib/CodeGen/LiveIntervalAnalysis.cpp:446: > void llvm::LiveInterval > s::handlePhysicalRegisterDef(llvm::MachineBasicBlock*, > llvm::MachineBasicBlock::iterator, llvm::SlotIndex, > llvm::MachineOperand&,

On Fri, 8 Jun 2012 08:49:32 -0700 Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jun 7, 2012, at 10:54 PM, Hal Finkel wrote: > > > For example, sometimes LiveIntervals asserts with: > > register: > > %CTR8 > > clang: /llvm-trunk/lib/CodeGen/LiveIntervalAnalysis.cpp:446: > > void llvm::LiveInterval > >

On Jun 7, 2012, at 7:31 PM, Hal Finkel wrote: > 112B BB#1: derived from LLVM BB %for.body, ADDRESS TAKEN > Predecessors according to CFG: BB#0 BB#1 > %vreg12<def> = PHI %vreg13, <BB#1>, %vreg11, <BB#0>;CTRRC8:%vreg12,%vreg13,%vreg11 > %vreg13<def> = COPY %vreg12<kill>; CTRRC8:%vreg13,%vreg12 > %vreg13<def> = BDNZ8 %vreg13,

On Thu, 7 Jun 2012 22:14:00 -0700 Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jun 7, 2012, at 7:31 PM, Hal Finkel wrote: > > > 112B BB#1: derived from LLVM BB %for.body, ADDRESS TAKEN > > Predecessors according to CFG: BB#0 BB#1 > > %vreg12<def> = PHI %vreg13, <BB#1>, %vreg11, > >

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

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 again, I am trying to implement an optimization pass for PowerPC such that simple loops use the special "counter register" (CTR) to track the induction variable. This is helpful because, in addition to reducing register pressure, there is a combined decrement-compare-and-branch instruction BZND (there are also other related instructions). I started this process by converting the

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

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

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