similar to: [LLVMdev] use/def/kill problem in LiveVariables.cpp

On May 19, 2011, at 7:47 AM, Jonas Paulsson wrote: > Hi, > > I am combining 16-bit registers to a 32 bit register in order to make a wide store, as per below: > > 732 %reg16506:hi16<def,dead> = COPY %reg16445<kill>; > 740 %reg16506:lo16<def> = COPY %reg16468<kill>; > 748 %r3<def,dead> = store %reg16506<kill>, %r3, > > As you can

I just enabled a new algorithm for computing live intervals that doesn't depend on LiveVariables. The goal is to get rid of the LiveVariables analysis completely, but unfortunately PHI elimination and the two-address pass still use LiveVariables for some optimizations. They don't require it, they work just fine without it at -O0. They use it to generate better code in some cases. The

Hi, I am combining 16-bit registers to a 32 bit register in order to make a wide store, as per below: 732 %reg16506:hi16<def,dead> = COPY %reg16445<kill>; 740 %reg16506:lo16<def> = COPY %reg16468<kill>; 748 %r3<def,dead> = store %reg16506<kill>, %r3, As you can see, LiveVariables has marked the high part dead, even though the super-register is used at

Evan, >A physical register cannot be live across the block. So it >must have a use in the block or it must be marked dead. From >your dump, it looks like the CCFLAGS defs are not being marked >dead. It's unclear where things went wrong, but you can step >through LiveVariables to debug this. Thanks for your response. I did quite some stepping through the llc passes, and it

On Apr 22, 2009, at 9:25 AM, Jakob Stoklund Olesen wrote: > Evan, thanks for clarifying. > > On 22/04/2009, at 17.45, Evan Cheng wrote: > >> I think you have probably run into a bug in one of the passes. It's >> probably the coalescer. It's tricky to get the sub-register liveness >> right. > > I think you are right. The bad kill seems to be introduced

Evan, thanks for clarifying. On 22/04/2009, at 17.45, Evan Cheng wrote: > I think you have probably run into a bug in one of the passes. It's > probably the coalescer. It's tricky to get the sub-register liveness > right. I think you are right. The bad kill seems to be introduced by the coalescer. I will take a look at it. I have written a machine code verifier pass that

I am trying to locate a bug that affects my Blackfin backend. I am having some trouble understanding the semantics of def/kill flags on machine operands when using subregisters. I compile this function: define void @i56_ls(i56 %x) nounwind { store i56 %x, i56* @i56_s ret void } And get this initial machine code: Live Ins: %R0 %R1 %reg1025D<def> = MOVE %R1 %reg1024D<def> =

On Apr 22, 2009, at 12:03 AM, Jakob Stoklund Olesen wrote: > I am trying to locate a bug that affects my Blackfin backend. I am > having some trouble understanding the semantics of def/kill flags on > machine operands when using subregisters. > > I compile this function: > > define void @i56_ls(i56 %x) nounwind { > store i56 %x, i56* @i56_s > ret void > } >

I though LiveVariables may be invalidated by LiveIntervals, but it's declared not: void LiveIntervals::getAnalysisUsage(AnalysisUsage &AU) const { AU.addPreserved<LiveVariables>(); AU.addRequired<LiveVariables>(); ... LiveInterval may coalesce virtual registers and remove identity moves instructions: bool LiveIntervals::runOnMachineFunction(MachineFunction &fn) {

A physical register cannot be live across the block. So it must have a use in the block or it must be marked dead. From your dump, it looks like the CCFLAGS defs are not being marked dead. It's unclear where things went wrong, but you can step through LiveVariables to debug this. Evan On Jan 9, 2009, at 2:50 AM, Christian Sayer wrote: > Hello, > > For my backend, I define and

I am observing poor instruction scheduling in my out-of-tree target. The problem is an over-constrained scheduling DAG. In particular, the DAG includes spurious output dependencies on physical, non-register-allocatable registers. MISched already includes code to avoid this problem. However that code relies on information clobbered by the earlier pass LiveVariables. I wonder whether this is a

I see, thanks. I used to work with GCC, which has an SSA-property verification run after each pass. It is surprising to find that LLVM does not check this! Jonas > Subject: Re: [LLVMdev] subregisters, def-kill > From: stoklund at 2pi.dk > Date: Thu, 19 May 2011 15:39:40 -0700 > CC: llvmdev at cs.uiuc.edu > To: jnspaulsson at hotmail.com > > > On May 19, 2011, at 7:47

On Feb 8, 2013, at 4:37 PM, Cameron Zwarich <zwarich at apple.com> wrote: > On Feb 8, 2013, at 4:20 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > >> On Feb 8, 2013, at 4:03 PM, Cameron Zwarich <zwarich at apple.com> wrote: >> >>> How much of the work is done here? I'd be happy to do the phi elimination part, since I basically did that

How much of the work is done here? I'd be happy to do the phi elimination part, since I basically did that for StrongPhiElimination (RIP). IIRC you run into a lot of problems with NEON subregister defs, which might be fixed by your new direct LiveIntervals implementation. Cameron On Feb 8, 2013, at 3:41 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > I just enabled a new

Is LiveVariables updated correctly when TII->RemoveBranch and TII->InsertBranch are called in the following piece of code? - MachineBasicBlock::updateTerminator() line 307 of MachineBasicBlock.cpp: if (FBB) { // The block has a non-fallthrough conditional branch. If one of its // successors is its layout successor, rewrite it to a fallthrough // conditional branch.

<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" > </div> <div dir="ltr" >Hi all,</div> <div dir="ltr" > </div> <div

Is there any way to discover whether a particular operand of a MachineInst participates in addressing? That is, if the MachineInst references memory, can I tell, given an operand, whether that operand is part of the address calculation for the instruction? Also, is there any reasonable way to get the set of machine instructions to which the output(s) of some machine instruction flows? The

On May 2, 2011, at 3:51 PM, Akira Hatanaka wrote: > - vreg81's VarInfo: > Alive in blocks: 5, 6, 7, 8, 10, 12, 13, 19, > Killed by: > #0: J <BB#17> > > > As you can see, VarInfo vreg81 is killed by the unconditional jump instruction of BB#20 when it should be killed by the newly created conditional branch in BB#14 (BEQ). Is this a bug in

On Apr 13, 2008, at 1:28 PM, Török Edwin wrote: > Hi, > > In PR2193 LiveVariables runs out of memory on a 512M limit, after > processing 11557 basicblocks. > VirtRegInfo has ~180000 entries with ~700 bytes each. > If I give it more memory (1.5G) it runs out of memory in LiveInterval. Some of the information kept by LiveVariables are somewhat redundant and can be removed. I

If I write %reg16506<def> = INSERT_SUBREG %reg16506, %reg16445, hi16; #1 %reg16506<def> = INSERT_SUBREG %reg16506, %reg16468, lo16; #2 store %reg16506 #3 it will not coalesce, as LiveVariables: on #2: %16506 gets #2 as a kill #3: %16506 gets #3 as an additional kill LiveIntervalAnalysis: