search for: killed

Displaying 20 results from an estimated 13261 matches for "killed".

Did you mean: filled
2012 May 09
2
[LLVMdev] register allocation problems in trunk with IMPLICIT_DEF
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>
2009 Apr 22
2
[LLVMdev] Def/Kill flags for subregisters
...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>...
2015 Feb 19
2
[LLVMdev] ScheduleDAGInstrs computes deps using IR Values that may be invalid
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
2014 Sep 05
5
[LLVMdev] [PATCH] [MachineSinking] Conservatively clear kill flags after coalescing.
..., %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/CodeGe...
2012 Oct 25
0
[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
2012 Oct 25
3
[LLVMdev] RegisterCoalescing Pass seems to ignore part of CFG.
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
2012 Oct 26
1
[LLVMdev] RegisterCoalescing Pass seems to ignore part of CFG.
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
2010 Jul 28
3
[LLVMdev] Subregister coalescing
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
2012 May 09
0
[LLVMdev] register allocation problems in trunk with IMPLICIT_DEF
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>,
2009 Apr 22
0
[LLVMdev] Def/Kill flags for subregisters
...> 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:...
2009 Jul 14
2
[LLVMdev] Kill-flag in two-address instruction tied operands
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.
2012 May 14
1
[LLVMdev] register allocation problems in trunk with IMPLICIT_DEF
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]
2010 Sep 04
3
[LLVMdev] Possible missed optimization?
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
2015 Feb 04
2
[LLVMdev] Handling of KILL instructions.
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,
2002 Jan 18
5
contrib/solaris/opensshd.in patch
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 ---
2017 Oct 09
4
{ARM} IfConversion does not detect BX instruction as a branch
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
2019 Nov 06
4
Possible Font problem with CentOS 7
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)
2014 Sep 05
3
[LLVMdev] [PATCH] [MachineSinking] Conservatively clear kill flags after coalescing.
...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/Machi...
2010 Sep 05
2
[LLVMdev] Possible missed optimization?
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
2018 Dec 13
5
dovecot/config processes one more time - which are safe to kill?
...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 )