similar to: [LLVMdev] Pass to compute livein info

This patch seems to have been lost on the llvm-commits mailing list. Would someone be able to review it? Thanks, Tom ________________________________________ From: llvm-commits-bounces at cs.uiuc.edu [llvm-commits-bounces at cs.uiuc.edu] on behalf of Tom Stellard [thomas.stellard at amd.com] Sent: Friday, February 03, 2012 1:55 PM To: llvm-commits at cs.uiuc.edu Subject: Re: [llvm-commits]

On Mon, Feb 13, 2012 at 10:17:11PM -0800, Lang Hames wrote: > Hi Tom, > > I'm pretty sure this function should only ever be called once, by > SelectionDAG. Do you know where the second call is coming from in your code? > > Cheers, > Lang. Hi Lang, I was calling EmitLiveInCopies() from one of my backend specific passes. If the function can only be called once, then

Hi Tom, I'm pretty sure this function should only ever be called once, by SelectionDAG. Do you know where the second call is coming from in your code? Cheers, Lang. On Mon, Feb 13, 2012 at 7:03 PM, Stellard, Thomas <Tom.Stellard at amd.com>wrote: > This patch seems to have been lost on the llvm-commits mailing list. > Would someone be able to review it? > > Thanks, >

Hi Tom, As far as I can tell EmitLiveInCopies is just there to handle physreg arguments and return values. Is there any reason for these to change late in your backend? - Lang. On Tue, Feb 14, 2012 at 7:22 AM, Tom Stellard <thomas.stellard at amd.com>wrote: > On Mon, Feb 13, 2012 at 10:17:11PM -0800, Lang Hames wrote: > > Hi Tom, > > > > I'm pretty sure this

- Please do not add any more uses of the LiveVariables pass! It is deprecated and only kept around for one last pass that isn't converted. All new code should use LiveIntervalAnalysis! - Kill flags are optional: If they are present they must be correct, but it is legal to have a value die without having a kill flag on the operand. So often a simple fix is to clear out the kill flags from

Hello Devs, Machine Instruction verifier pass always validates Live variable info associated with MachineInstr along with other checks. Please consider following scenario (w.r.t bugZilla 32583) 1/ MachineCSE pass may prohibit optimising out a common sub-expression for instruction using physical registers by looking at the LiveIn info of successor basic blocks. 2/ Which means we need Live

I would like to maintain the livein information for physical registers on basic blocks past register allocation, or recreate it if possible. The goal is to be able to run a late pass of DeadMachineInstrElim, which requires valid livein information. The X86 target returns false for requiresRegisterScavenging so passes like BranchFolding don't update the livein information. At that point I

Hi again, 2009/1/13 Evan Cheng <evan.cheng at apple.com>: > > > On Jan 13, 2009, at 12:27 AM, Roman Levenstein <romix.llvm at googlemail.com> > wrote: > >> 2009/1/13 Evan Cheng <echeng at apple.com>: >>> >>> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: >>> >>>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:

Hi, I have ported LLC to a risc cpu. It can pass benchmark that I have at current. But I want do some optimization after register alloction by adjusting register using. I scan MachineBasicBlock to analyze operand's IsKill, IsDead , IsDef attribute to get a physical register's liverange. But I get a strange case at MBB.jpg. R4 is marked <kill> at MBB0. If I scan R4's

On Jan 13, 2009, at 12:27 AM, Roman Levenstein <romix.llvm at googlemail.com > wrote: > 2009/1/13 Evan Cheng <echeng at apple.com>: >> >> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: >> >>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: >>> Predecessors according to CFG: 0x8fdac90 (#0) >>> %R0<def> = MOVi 0, 14, %reg0,

While beginning to add vector registers to a back end I came across the following problem: as soon as I define two sets of registers that have a many-to-one mapping the live interval pass appears to double- kill the mapped-onto register. I have the following excerpts from my RegisterInfo.td. def V4R0 : R4v<0 , "V4R0 ", []>, DwarfRegNum<0>; def R0 : Rg<0 ,

On Jan 14, 2010, at 6:39 PM, 任坤 wrote: > But I want do some optimization after register alloction by adjusting > register using. I scan MachineBasicBlock to analyze operand's IsKill, IsDead , IsDef attribute to get a physical register's liverange. But I get a strange case at MBB.jpg. You can also look at RegisterScavenging.cpp and MachineVerifier.cpp. They are doing the same

On Mar 25, 2007, at 7:12 AM, Christopher Lamb wrote: > While beginning to add vector registers to a back end I came across > the following problem: as soon as I define two sets of registers > that have a many-to-one mapping the live interval pass appears to > double-kill the mapped-onto register. I have the following excerpts > from my RegisterInfo.td. > > def V4R0

2009/1/13 Evan Cheng <echeng at apple.com>: > > On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: > >> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: >> Predecessors according to CFG: 0x8fdac90 (#0) >> %R0<def> = MOVi 0, 14, %reg0, %reg0 >> *** STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4) >> [0x8fc2d68 + 0]

Hi all, A question about statically linking a pass to clang instead of dynamically loading it at runtime. I am stumped on this bug for a while. I inserted a pass under lib/Transforms/mypass directory, registered it with INITIALIZE_PASS and defined createMyPass in the pass. Also I added file mypass.h in include/llvm/Transforms/ to expose the accessor functions that expose my passes. Entries are

Hi all, I am really stumped on a problem for long. I could not figure out why. That is why i am here. OK, here is the problem: I tried to insert a MachineBasicBlock into a function. Here is the code snippet: // insert a machine basic block with the error_label into MF and before I // Pred is the predecessor of the block to be inserted // the new basic block is inserted right before I void

Thanks -- View this message in context: http://llvm.1065342.n5.nabble.com/is-liveIns-in-machineBasicBlock-only-valid-for-first-block-in-machine-function-tp63667.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

The pass you're referring to is in include/llvm/Analysis/LiveValues.h and lib/Analysis/LiveValues.cpp. It computes conservative approximations for specific liveness queries, rather than full livein/liveout information. It's intended to be used as a heuristic. Dan On May 30, 2009, at 3:51 PM, Evan Cheng wrote: > I believe Dan has added a pass to compute livein / liveout values. >

I was looking at the SymbolTable code in LLD COFF and ELF recently, and I’m confused by the use of CachedHashStringRef. From what I understand, a CachedHashStringRef combines a StringRef with a computed hash. There’s no caching going on in the CachedHashStringRef itself; that is, if you construct CachedHashStringRef("foo"), and then construct a second

If int_guard_load returns a pointer based on the passed-in pointer, it captures it (at least according to the definition of "capture" which NoCapture uses). -Eli On Thu, Oct 6, 2011 at 2:26 PM, Zeng Bin <ezengbin at gmail.com> wrote: > It does not do anything. It is an abstract function which transforms a > pointer and returns another pointer of the same type. It does not