search for: dead

...;m currently failing the following assertion: llc: VirtRegMap.cpp:1733: void<unnamed>::LocalSpiller::RewriteMBB(llvm::MachineBasicBlock&, llvm::VirtRegMap&): Assertion `KillRegs[0] == Dst' failed. when attempting to allocate this machine function: entry: 4 %reg1024<def,dead> = MOV32rr %EDI<kill> 12 %reg1025<def,dead> = MOV64rr %RSI<kill> 20 ADJCALLSTACKDOWN 0, %ESP<imp-def>, %EFLAGS<imp-def,dead>, %ESP<imp-use> 28 %reg1026<def> = MOV8ri 4 36 %reg1027<def> = FsFLD0SD 44 %reg1028<def> = LE...

...t; > llc: VirtRegMap.cpp:1733: > void<unnamed>::LocalSpiller::RewriteMBB(llvm::MachineBasicBlock&, > llvm::VirtRegMap&): Assertion `KillRegs[0] == Dst' failed. > > > when attempting to allocate this machine function: > > entry: > 4 %reg1024<def,dead> = MOV32rr %EDI<kill> > 12 %reg1025<def,dead> = MOV64rr %RSI<kill> > 20 ADJCALLSTACKDOWN 0, %ESP<imp-def>, %EFLAGS<imp-def,dead>, > %ESP<imp-use> > 28 %reg1026<def> = MOV8ri 4 > 36 %reg1027<def> = FsFLD0SD >...

...24 = MOV8r0 MOV8r0 %reg1024<d> 20 %reg1025 = LEA64r %NOREG, 1, %NOREG, <ga:initialized$$$CFE_id_cc092431_main> LEA64r %reg1025<d> %mreg(0) 1 %mreg(0) <ga:initialized$$$CFE_id_cc092431_main> 24 %RDI = MOV64rr %reg1025<kill> MOV64rr %mreg(78)<d> %reg1025 28 %AL<dead> = MOV8rr %reg1024<kill>, %EAX<imp-def> MOV8rr %mreg(2)<d> %reg1024 %mreg(17)<d> 32 CALL64pcrel32 <ga:printf>, %RDI<kill>, %RAX<imp-def>, %RCX<imp-def,dead>, %RDX<imp-def,dead>, %RSI<imp-def,dead>, %RDI<imp-def,dead>, %R8<imp...

Most of the states were calling SET_NEXT_STATE(%.DEAD) then using return -1 on error, to reflect the fact that they had also called set_error() and wanted the caller to notice the failure. Unfortunately, the state machine engine refuses to run the entry code of the next state when the current state returned -1, which meant the DEAD state entry code ne...

On Jun 26, 2007, at 11:20 AM, David A. Greene wrote: > > 28 %AL<dead> = MOV8rr %reg1024<kill>, %EAX<imp-def> > MOV8rr %mreg(2)<d> %reg1024 %mreg(17)<d> > 32 CALL64pcrel32 <ga:printf>, %RDI<kill>, %RAX<imp-def>, %RCX<imp- > def,dead>, > %RDX<imp-def,dead>, %RSI<imp-def,dead>, %RDI<imp-def,...

...%R0<def> = MOVi 20, 14, %reg0, %reg0 0xe3a00014 JIT: 0x4512e01c: STR %R0<kill>, %SP, %reg0, 4, 14, %reg0, Mem:ST(4,4) [b + 0] 0xe58d0004 JIT: 0x4512e020: %R0<def> = ADDri %SP, 4, 14, %reg0, %reg0 0xe28d0004 JIT: 0x4512e024: BL <ga:add1>, %R0<kill>, %R0<imp-def,dead>, %R1<imp-def,dead>, %R2<imp-def,dead>, %R3<imp-def,dead>, %R12<imp-def,dead>, %LR<imp-def,dead>, %D0<imp-def,dead>, %D1<imp-def,dead>, %D2<imp-def,dead>, %D3<imp-def,dead>, %D4<imp-def,dead>, %D5<imp-def,dead>, %D6<imp-def,dea...

Evan, thanks for responding so quickly. On Tuesday 26 June 2007 14:11, Evan Cheng wrote: > On Jun 26, 2007, at 11:20 AM, David A. Greene wrote: > > 28 %AL<dead> = MOV8rr %reg1024<kill>, %EAX<imp-def> > > MOV8rr %mreg(2)<d> %reg1024 %mreg(17)<d> > > 32 CALL64pcrel32 <ga:printf>, %RDI<kill>, %RAX<imp-def>, %RCX<imp- > > def,dead>, > > %RDX<imp-def,dead>, %RSI<imp-def,dead&gt...

...answer about. >> >> In our out-of-tree target we've been doing some bundling before register allocation for quite some time now, and last night a new problem popped up. What the fix should be depends on if this bundle is legal or not: >> >> BUNDLE %vreg39<imp-def,dead> >> * %vreg39:hiAcc<def> = mv_ar16_ar16_lo16In32 %vreg37 >> [...] >> >> %vreg39 isn't used after the bundle so the dead-marking in the BUNDLE is correct. However, the def in the actual bundled instruction defining %vreg39 is not marked with dead. >&g...

...ding subregisters. But I think the problem posted by Mikael just happened to involve subregisters, and the discussions about subregisters is confusing when it comes to Mikaels original question/problem. I think that the bundle could look something like this just as well: BUNDLE %vreg1<def,dead> * %vreg1<def> = add %vreg2, %vreg3 * call @foo, %vreg1<internal-use> No subregisters involved. %vreg1 is dead after the bundle. %vreg1 is not dead when defined at the "add", because it is used later in the same bundle. Should perhaps the %vreg1 not be inclu...

On Jun 26, 2007, at 12:57 PM, David Greene wrote: > Evan, thanks for responding so quickly. > > On Tuesday 26 June 2007 14:11, Evan Cheng wrote: >> On Jun 26, 2007, at 11:20 AM, David A. Greene wrote: >>> 28 %AL<dead> = MOV8rr %reg1024<kill>, %EAX<imp-def> >>> MOV8rr %mreg(2)<d> %reg1024 %mreg(17)<d> >>> 32 CALL64pcrel32 <ga:printf>, %RDI<kill>, %RAX<imp-def>, %RCX<imp- >>> def,dead>, >>> %RDX<imp-def,dead>, %RSI<imp...

> On Jun 27, 2017, at 2:44 PM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 6/27/2017 4:35 PM, Quentin Colombet via llvm-dev wrote: >> Yeah I was reading this as “only the non-touched part are dead”, and that’s what I’d like to see in the representation longer. Obviously, the register is not dead as a whole here :) > > I think that having two defs for the same register, one dead and one not dead simply doesn't make sense. We already assume that a register is live if at least a part...

...;kill>, 14, %NOREG, %NOREG %r1 = MOVr %r5<kill>, 14, %NOREG, %NOREG %r2 = LDR <fi#1>, %NOREG, 0, 14, %NOREG %r3 = MOVr %r4, 14, %NOREG, %NOREG BL <ga:gimplify_cond_expr>, %r0<kill>, %r1<kill>, %r2<kill>, %r3<kill>, %r0<imp-def>, %r1<imp-def,dead>, %r2<imp-def,dead>, %r3<imp-def,dead>, %r12<imp-def,dead>, %lr<imp-def,dead>, %d0<imp-def,dead>, %d1<imp-def,dead>, %d2<imp-def,dead>, %d3<imp-def,dead>, %d4<imp-def,dead>, %d5<imp-def,dead>, %d6<imp-def,dead>, %d7<imp-def,...

You are right about your interpretation of "dead". The case here is that RSP is a reserved register and so its liveness isn't really tracked. The "implicit-def dead" is an idiom used to mean that the register (reserved or not) is clobbered. The other implicit uses/defs can come from instruction definitions to indicate that...

Hi, My understanding of a "dead" register is a def that is never used. However, when I dump the MI after reg alloc on a simple program I see the following sequence: ADJCALLSTACKDOWN64 0, 0, 0, *implicit-def dead %rsp*, implicit-def dead %eflags, implicit-def dead %ssp, implicit %rsp, implicit %ssp CALL64pcrel32 @foo, <re...

...t you might have an opinion or answer about. In our out-of-tree target we've been doing some bundling before register allocation for quite some time now, and last night a new problem popped up. What the fix should be depends on if this bundle is legal or not: BUNDLE %vreg39<imp-def,dead> * %vreg39:hiAcc<def> = mv_ar16_ar16_lo16In32 %vreg37 [...] %vreg39 isn't used after the bundle so the dead-marking in the BUNDLE is correct. However, the def in the actual bundled instruction defining %vreg39 is not marked with dead. Is the above bundle ok or not?...

I have a usb hd that I use for backup. Occasionally it dies. scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device Buffer I/O error on device sdc1, logical block 0 lost page write due to I/O error on sdc1 EXT2-fs error (device sdc1): read_inode_bitmap: Cannot read inode bitmap...

> On Jun 28, 2017, at 5:10 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Oh wait, vreg1 is indeed used. > Yeah, having a dead flag here sounds wrong. I mean on the instruction itself. On the bundle, that’s debatable. That would fit the semantic “if no side effect you can kill it” (here there is side effect, we define other vregs). > >> On Jun 28, 2017, at 2:28 AM, Björn Pettersson A <bjorn.a.pettersson at e...

...0/05/2010, at 3:01 AM, Chris Lattner wrote: > > On May 19, 2010, at 7:07 AM, o.j.sivart at gmail.com wrote: > >> Hi all, >> >> I'm interested in the impact of representing code via intrinsic functions, in contrast to via an instruction, when it comes to performing dead instruction/code elimination. As a concrete example, lets consider the simple case of the llvm.*.with.overflow.* intrinsics. >> >> If I have some sequence (> 1) of llvm.*.with.overflow.* intrinsics, as in the form of: >> >> @global = global i32 0 >> >> defi...

Anyone have any clues about how to sanitize a dead SSD? We haven't had it yet, but we're sure it's coming. Esp. since I'm a federal contractor, a dead disk gets deGaussed, but what the hell do you do with a SSD?

I saw there is reference to dead def on registers in LLVM source code. I am not aware of this concept from the traditional course material. What are the properties of dead def? Cheers Thomson -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20...