similar to: [LLVMdev] Register Coalescer does not preserve TargetFlag

Do you know any backend that implement instructions as a flag modifier in instruction ? Thank, Vincent Lejeune ----- Mail original ----- > 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)" <llvmdev at cs.uiuc.edu> > Envoyé le : Lundi 6 août 2012 20h06 >

On Aug 6, 2012, at 11:00 AM, Vincent Lejeune <vljn at ovi.com> wrote: > Ok. > > I tried to do it using a pass after register allocation, lowering NEG/ABS instructions. > However I met a problem : apparently getNextOperandForReg() can returns a MachineOperand before the one I'm processing. > > The following code snippet : > > > void

On Aug 6, 2012, at 11:12 AM, Vincent Lejeune <vljn at ovi.com> wrote: > Do you know any backend that implement instructions as a flag modifier in instruction ? No, I am not aware that any of the targets in the tree do something like that. TargetFlags is used by ARM to modify global symbol operands and such. But I meant you should be looking at the coding style used in the other

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

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

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

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 Aug 6, 2012, at 11:16 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > The getNextOperandForReg() function isn't used anywhere, Should we remove it? -Jim

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

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

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 >

On Aug 6, 2012, at 10:45 AM, Vincent Lejeune <vljn at ovi.com> wrote: > Is it possible to "customise" INSERT_SUBREG and COPY instructions to add them an immediate operands ? > I know that COPY is lowered using copyPhysReg() function in MachineTargetInstrInfo, but I'm not sure there is something equivalent for INSERT_SUBREG. No, these instructions must be pure register

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

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

> > 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 Quentin, On 08/15/14 19:01, Quentin Colombet wrote: [...] >> The question is: How should true subregister definitions be >> expressed so that they do not interfere with each other? See the >> detailed problem description below. > > We do have a limitation in our current liveness tracking for > sub-register. Therefore, I am not sure that is possible. > >

Hi, I'm having an issue with subregisters on my target. With a pseudo that writes to a 32 bit reg: %vreg20<def> = toHi16_low0_pseudo %vreg2; reg32:%vreg20 hi16:%vreg2 expands to %vreg2<def> = COPY %a2h; hi16:%vreg2 %vreg43<def> = mov 0, pred:0, pred:%noreg, %ac0<imp-use>, %ac1<imp-use>; lo16:%vreg43 %vreg20<def> =

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

Hello, I have random errors that I can not analyze nor fix: when several users connect to the same Samba share, they get sometimes error messages "the local drive name is already in use. This connection has not been restored", although the connection is still usable afterwards. This sometimes breaks a file operation. Clients are running Windows 2000, and the server is a Solaris 8