similar to: [LLVMdev] Strong vs. default phi elimination and single-reg classes

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,

Hi, I've been looking at the Machine Scheduler on Power PC. I am looking only at the pre-RA machine scheduler and I am running it in the default bi-directional mode (so, both top down and bottom up queues are considered). I've come across an example where the scheduler picks a poor ordering for the instructions which results in very high register pressure which results in spills.

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, 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. I don't know if it's a bug of the pass, or if my backend should do something

> On Oct 13, 2017, at 1:46 PM, Matthias Braun <matze at braunis.de> wrote: > > Yes, I've run into the problem myself that the Pending queue isn't even checked with the tryCandidate() logic and so takes priority over all other scheduling decisions. > > I personally would be open to changes in this area. To start the brainstorming I could imagine that we move nodes

Hi, I don't know if my llvm ir code is faulty, or if I spot a bug in the RegisterCoalescing Pass, so I'm posting my issue on the ML. Shader and print-before-all dump are given below. The interessing part is the vreg6/vreg48 reduction : before RegCoalescing, the machine code is : // BEFORE LOOP ... Some COPYs.... 400B%vreg47<def> = COPY %vreg2<kill>; R600_Reg32:%vreg47,%vreg2

On Wed, Feb 8, 2017 at 6:21 PM, Wei Mi <wmi at google.com> wrote: > I have an issue that I've been wrestling with for quite some time and I'm > hoping that someone with a deeper understanding of the register allocator > can help me with. > > Namely, I am trying to teach RA to split a live range rather than > allocating a CSR. I've attempted a very large number

Hi Vincent, On 24/10/2012 23:26, Vincent Lejeune wrote: > Hi, > > I don't know if my llvm ir code is faulty, or if I spot a bug in the RegisterCoalescing Pass, so I'm posting my issue on the ML. Shader and print-before-all dump are given below. > > The interessing part is the vreg6/vreg48 reduction : before RegCoalescing, the machine code is : > > // BEFORE LOOP >

I have an issue that I've been wrestling with for quite some time and I'm hoping that someone with a deeper understanding of the register allocator can help me with. Namely, I am trying to teach RA to split a live range rather than allocating a CSR. I've attempted a very large number of tweaks to the costs (both existing and experimental ones that I've added). However, despite all

Thank for your help. You're right, merging vreg32 and vreg48 is perfectly fine, sorry I missed that. I "brute force" debuged by adding MachineFunction dump after each join, I think I found the issue : it's when vreg32 and vreg10 are merged. vreg10 only appears in BB#3, and the join only occurs in BB#3 apparently even if vreg32 lives in the 4 machine blocks After joining, there

Vincent, File a bug report so you can get a fix for it. Ivan On 25/10/2012 23:01, Vincent Lejeune wrote: > Thank for your help. You're right, merging vreg32 and vreg48 is perfectly fine, sorry I missed that. > I "brute force" debuged by adding MachineFunction dump after each join, I think I found the issue : it's when vreg32 and vreg10 are merged. > vreg10 only

Hi, I am working on a backend for a CGRA architecture with advanced predicate support (as on EPIC machines and as first used in the OpenIMPACT compiler). Until last month, the backend was working fine, but since the r161643 commit by stoklund, my backend doesn't work anymore. I think I noticed some related commits later on, and the assertion I get on the latest trunk (r164162) differs from

> > PHIElim and TwoAddress passes leave SSA form. > May be a missed something in your code but %vreg48 seems to be there > after PHI elimination. PHIElim tags those kind of registers as being > PHIJoin regs, updating LiveVariables pass, so the regcoalescer is aware > of them (some SSA info is still alive but the reg coalescer will > invalidate that information after

On Sep 18, 2012, at 1:45 PM, Bjorn De Sutter <bjorn.desutter at elis.ugent.be> wrote: > I am working on a backend for a CGRA architecture with advanced predicate support (as on EPIC machines and as first used in the OpenIMPACT compiler). Until last month, the backend was working fine, but since the r161643 commit by stoklund, my backend doesn't work anymore. I think I noticed some

Hi, Recently code using IMPLICIT_DEF and INSERT_SUBREG started to break: %vreg9<def> = IMPLICIT_DEF %vreg10<def> = INSERT_SUBREG %vreg9<kill>, %vreg1<kill>, hi %vreg12<def> = sub %vreg10<kill>, %vreg11<kill> => %vreg10<def> = IMPLICIT_DEF %vreg10:hi<def> = COPY %vreg1<kill>

Hi Vincent, On 25/10/2012 18:14, Vincent Lejeune wrote: > When examining the debug output of regalloc, it seems that joining 32bits reg also joins 128 parent reg. > > If I look at the : > %vreg34<def> = COPY %vreg6:sel_y; R600_Reg32:%vreg34 R600_Reg128:%vreg6 > > instructions ; it gets joined to : > 928B%vreg34<def> = COPY %vreg48:sel_y; > > when vreg6 and

Hi, I'm trying to understand how virtual regs are assigned to operands in IR instructions. I looked into SelectionDAG but could not figure out where the assignment happens. How and where does this conversion happen? Furthermore, I want to build a map between variable and the virtual register (x corresponds to vreg11 in below code). I've been stuck here for a while. Any help is greatly

On May 9, 2012, at 6:27 AM, Jonas Paulsson <jonas.paulsson at ericsson.com> wrote: > Hi, > > Recently code using IMPLICIT_DEF and INSERT_SUBREG started to break: > > %vreg9<def> = IMPLICIT_DEF > %vreg10<def> = INSERT_SUBREG %vreg9<kill>, %vreg1<kill>, hi > %vreg12<def> = sub %vreg10<kill>,

I used llvm-stress to find a similar problem on x86-64. See http://llvm.org/bugs/show_bug.cgi?id=12821. BTW, llvm-stress is a great tool! /Patrik Hägglund ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Jakob Stoklund Olesen Sent: den 9 maj 2012 18:21 To: Jonas Paulsson Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev]

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