similar to: [LLVMdev] RegisterCoalescing Pass seems to ignore part of CFG.

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

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

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

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 vreg48 are joined. It's right. But joining the following copy 

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

Hi, R600 hardware (Radeon gfx card) does neither have a NEG nor an ABS instruction ; however any sources operand can be negated/abs'd by setting a bit for every source operand in the final bytecode (but not DST). A good way of modeling this behavior in LLVM is by using TargetFlag on operand. Currently the R600 LLVM backend in Mesa lower NEG and ABS DAG instruction to a MOV + TargetFlag using

Hi, The R600 backend uses the register coalescer pass to generate code. This pass has a EnablePhysicalJoin boolean value which is set to false by default. The way the R600 backend is used in Mesa runtime makes it very usefull to be set to true : We use live inst to represent OpenGL Input, which are converted to vreg = COPY %PhysReg after instruction selection. For instance, the following sample

Hi Tom, Thanks a lot for your explanations, now it makes a lot more sense ;) I had a slightly closer look at the R600 packetizer, and the issue is that the third LSHL instruction has both an implicit use and *afterwards* an implicit def of T1_XYZW. The latter def causes the current ScheduleDAGInstrs implementation to ignore the implicit use, thus the ScheduleDAG only contains an

Tom, On Aug 21, 2012, at 11:21 AM, Tom Stellard <thomas.stellard at amd.com> wrote: > I've been working on replacing the MachineOperand flags in the R600 > backend with immediate operands, but I can't figure out how to modify > the instruction patterns to make this work. For example, I have the class: > > class R600_1OP <bits<32> inst, string opName,

On Mon, Aug 20, 2012 at 04:30:13PM -0700, Jakob Stoklund Olesen wrote: > All, > > The code generator operand class, MachineOperand, has an 8-bit TargetFlags field that the individual targets can use as they please. X86 and ARM use it to encode linker magic on symbol operands. > > It has been mentioned a couple of times on this list that it is not safe to use TargetFlags on

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Owen Anderson > Sent: Tuesday, August 21, 2012 11:37 AM > To: Stellard, Thomas > Cc: llvmdev at cs.illinois.edu > Subject: Re: [LLVMdev] No more TargetFlags on MO_Register > MachineOperands > > Tom, > > On Aug 21, 2012, at 11:21 AM, Tom

Hello, The ScheduleDAGInstrs::buildSchedGraph() function creates def/uses lists by iterating over all instruction operands and calls addPhysRegDeps() if used post-RA (line ~770 ff.). If an operand is a def, the uses of that registers are cleared (ScheduleDAGInstrs.cpp:333: Uses.eraseAll(Reg); ). As a consequence, if an instruction has an explicit use of a register and an implicit def of the

On Aug 22, 2012, at 11:34 AM, "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > > >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Owen Anderson >> Sent: Tuesday, August 21, 2012 11:37 AM >> To: Stellard, Thomas >> Cc: llvmdev at cs.illinois.edu >>

On Sun, Mar 24, 2013 at 12:50:02PM -0700, Jakob Stoklund Olesen wrote: > I have updated TableGen to support a new format for instruction selection patterns. > > Before: > > def : Pat<(subc IntRegs:$b, IntRegs:$c), (SUBCCrr IntRegs:$b, IntRegs:$c)>; > > After: > > def : Pat<(subc i32:$b, i32:$c), (SUBCCrr $b, $c)>; > > Since the pattern matching

All, The code generator operand class, MachineOperand, has an 8-bit TargetFlags field that the individual targets can use as they please. X86 and ARM use it to encode linker magic on symbol operands. It has been mentioned a couple of times on this list that it is not safe to use TargetFlags on register operands. This is because many target-independent passes are manipulating register operands

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

I have updated TableGen to support a new format for instruction selection patterns. Before: def : Pat<(subc IntRegs:$b, IntRegs:$c), (SUBCCrr IntRegs:$b, IntRegs:$c)>; After: def : Pat<(subc i32:$b, i32:$c), (SUBCCrr $b, $c)>; Since the pattern matching happens on a DAG with type labels, not register classes, I think it makes more sense to specify types directly on the input

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