search for: kille

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>

...they were fully implemented? Here is my theory: 1. def/kill applies to all subregisters, so %R1<kill> will kill R1, R1L, and R1H 2. Liveness of a register can be correctly inferred from the def/kill flags. This seems to be the assumption of the register scavenger. 3. A register must be killed before it can be defined again. Is this theory correct? If so, it would be necessary to sprinkle extra <imp-use,kill> here and there, like I have done above. Here is an X86 example: %EAX<def> = MOV32rm %ESP, 1, %noreg, 8, %noreg, Mem:LD(4,4) [FixedStack-2 + 0] %ECX<def>...

Hi All, I've encountered an issue where tail merging MIs is causing a problem with the post-RA MI scheduler dependency analysis and I'm not sure of the best way to address the problem. In my case, the branch folding pass (lib/CodeGen/BranchFolding.cpp) is merging common code from BB#14 and BB#15 into BB#16. It's clear that there are 4 common instructions (marked with an *) in BB#14

..., %vreg520<kill> >>> >>> => was coalesced into => >>> >>> %vreg568<def,tied1> =add%vreg341<tied0>, %vreg368<kill> >>> >>> MachineVerifierthen complained: >>> *** Bad machine code: Virtual register killed in block, but needed live out. *** >>> >>> The kill flag for %vreg368 is incorrect, and is cleared by this patch. >>> >>> This is similar to the clearing done at the end of >>> MachineSinking::SinkInstruction(). >>> --- >>> lib/CodeG...

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

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 all, We are working on a backend for a machine that has 4-wide vector register & ops, *but* not vector loads. All the vector register elements are directly accesible, so VI1 reg (Vector Integer 1) has I4, I5, I6 and I7 as its (integer) subregisters. Subregisters of same reg *never* overlap. Therefore, vector loads are lowered to scalar loads followed by a chain of INSERT_VECTOR_ELTs. Then

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

...> Here is my theory: > > 1. def/kill applies to all subregisters, so %R1<kill> will kill R1, > R1L, and R1H > 2. Liveness of a register can be correctly inferred from the def/kill > flags. This seems to be the assumption of the register scavenger. > 3. A register must be killed before it can be defined again. > > Is this theory correct? Yes. > > If so, it would be necessary to sprinkle extra <imp-use,kill> here and > there, like I have done above. > > Here is an X86 example: > > %EAX<def> = MOV32rm %ESP, 1, %noreg, 8, %noreg, Mem...

Hi, Two-address instructions are represented as normal three-address instructions with a Desc bit that indicates the first two operands are tied together. The question is, should the second operand have a <kill> flag? a: %R0<def> = MUL %R0, %R1<kill> b: %R0<def> = MUL %R0<kill>, %R1<kill> I think the current policy is a: There should be no kill-flag.

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 Sep 4, 2010, at 11:21 AM, Borja Ferrer wrote: > I've noticed this pattern happening with other operators aswell, but used xor in this example. As i said before, i tried with different register allocation orders, but it will produce always the same result. GCC is emitting longer code, but since LLVM is so nearer to the optimal code sequence i wanted to reach it. In LLVM, copies are

Hi all, My understanding is that we keep around KILL instructions in order to keep the results of the various register liveness analysis passes valid. Consider for example the following machine basic block: BB#0: derived from LLVM BB %entry Live Ins: %A0_64 %A1_64 %V0_64<def> = AND64 %A0_64<kill>, %A1_64<kill> %V0<def> = KILL %V0,

This patch adds the seatbelts which _only_ kill parent sshd procs... -RMallory (eg: when you ssh into a machine and pkgadd the new openssh, it will not kill your current (or anyone else's sshd session) onanother_note: the buildpkg.sh could use some exec_prefix functionality... to deal with ./configure --prefix= --exec_prefix=/usr *** bak/opensshd.in Fri Oct 19 13:36:24 2001 ---

Hi all, I got a silly bug when compiling our project with the latest Clang. Here's the outputted assembly: > tst r3, #255 > strbeq r6, [r7] > ldreq r6, [r4, r6, lsl #2] > strne r6, [r7, #4] > ldr r6, [r4, r6, lsl #2] > bx r6 For the code to execute correctly, either the _ldr_ should be a _ldrne_ instruction or the _ldreq_ instruction should be removed. The error seems to

Hi, I've got a possible font problem with a fully updated CentOS 7 system. An example with the man command. #man kill Should return the following KILL(1) User Commands KILL(1) NAME kill - terminate a process SYNOPSIS kill [-s signal|-p] [-q sigval] [-a] [--] pid... kill -l [signal] but what I actually get is the following KILL(1)

...t;def> = COPY %vreg368 %vreg568<def,tied1> = add %vreg341<tied0>, %vreg520<kill> => was coalesced into => %vreg568<def,tied1> = add %vreg341<tied0>, %vreg368<kill> MachineVerifier then complained: *** Bad machine code: Virtual register killed in block, but needed live out. *** The kill flag for %vreg368 is incorrect, and is cleared by this patch. This is similar to the clearing done at the end of MachineSinking::SinkInstruction(). --- lib/CodeGen/MachineSink.cpp | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/lib/CodeGen/Mach...

On Sep 4, 2010, at 5:40 PM, Eli Friedman wrote: > If you want to take a look at this yourself, the issue is easy to > reproduce with Thumb1: Thanks, Eli. Nice catch! This IR: target triple = "thumbv5-u-u" define arm_aapcscc i64 @foo(i64 %a, i64 %b) nounwind readnone { entry: %xor = xor i64 %a, 18 ; <i64> [#uses=1] %xor2 = xor i64 %xor, %b

...m total used free shared buff/cache available Mem: 64437 23676 37822 0 2939 Currently on dovecot 2.3.3. I guess it's very low priority to handle that, so: how can I figure out which dovecot/config processes are safe to be killed by external script? Does "all beside 2 newest ones" rule look sane? Thanks, -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )