similar to: [LLVMdev] LiveIntervals::handlePhysicalRegisterDef, unreachable MBBs

On Fri, 2004-07-09 at 05:02, Vladimir Prus wrote: > I've just spend some time looking at the above function, and while I > understood what it does, a comment would have helped a lot. Thanks for bringing this to my attention! > Maybe, something like: > > // Determine the end of the live interval for this register > // For physical register, all internvals are within basic

On Mar 27, 2007, at 3:25 PM, Evan Cheng wrote: > > 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

On Apr 3, 2007, at 3:45 PM, Christopher Lamb wrote: > >> Can you dump out the machine basic block? It should have an >> implicit use of V4R0 at first ORI but it should not be marked kill. >> If it is marked kill, then you need to walk LiveVariables.cpp to >> find out why. > > Here is the beginning of the BB dump. > > entry (0x8503c80, LLVM BB @0x8501af0,

Hello, For my backend, I define and use a CC register similiarly to the EFLAGS register in X86 (I call it CCFLAGS). But if I make all arithmetic/logic instructions affect it ('let Defs = [CCFLAGS] in...' in InstrInfo.td) I run into // The only case we should have a dead physreg here without a killing or // instruction where we know it's dead is if it is live-in to the function

I guess isUnpredicatedTerminator() and friends would just return false, but maybe there should be an assertion in an earlier pass that all instructions in the tail position of basic blocks really are terminators, or is that not required? // A On 9/29/07, Evan Cheng <evan.cheng at apple.com> wrote: > Yeah, that will cause problems. However, I expect an assertion > somewhere. Any

On Jan 23, 2013, at 12:36 PM, Stefan Hepp <stefan at stefant.org> wrote: > However, an alternative option could be to simply disallow different edge weights for edges with the same source and destination, or to make the call to getEdgeFreq(Pred,BB) in BlockFrequencyImpl distinguish between the edges, which would eliminate the need for an additional PtrSet, but is not that easy to

Hi, On 01/23/2013 11:30 PM, Jakob Stoklund Olesen wrote: > If you can find the place that creates the duplicate MBB edge, that would be great. > Found it :) It happens in lib/CodeGen/IfConversion.cpp at the very end in MergeBlocks. I attached a small patch that should resolve that issue. Our tests now compile sucessfully even without my previous patch. regards, Stefan --------------

Yeah, that will cause problems. However, I expect an assertion somewhere. Any chance you can track down the exact problem? Thanks. Evan On Sep 28, 2007, at 1:37 PM, Andreas Fredriksson <deplinenoise at gmail.com> wrote: > Replying to my self here. It seems I was missing an isTerminator = 1 > on the branch instruction in question, so LLVM didn't know that the >

Replying to my self here. It seems I was missing an isTerminator = 1 on the branch instruction in question, so LLVM didn't know that the instruction terminated a basic block. Does that make sense, or is just masking some other problem? Thanks, Andreas On 9/28/07, Andreas Fredriksson <deplinenoise at gmail.com> wrote: > Hi, > I'm trying to write up my little m68k backend

We are developing a new backend for a custom processor using LLVM. After updating to LLVM 3.2, we run into an assertion in BlockFrequencyImpl.h. The offending test-case looks basically like this: for ( ... ) { switch (i) { case 100: // do something break; case 102: // do something else break; case 103: // do some more break; case 104: // now something different

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) {

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

On Wed, 2005-09-07 at 18:24 +0800, Tzu-Chien Chiu wrote: > 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

Hi, I'm trying to write up my little m68k backend things have been going smoothly. I've been working with the x86 backend as a template, fixing things as I go. Now I've run into branches and I have a crash I don't really understand. Here's the sample IR I'm running llc on to generate assembly: define i32 @ilog2(i32 %x) { entry: %tmp718 = icmp eq i32 %x, 0

On 08/09/05, Alkis Evlogimenos <evlogimenos at gmail.com> wrote: > to those coalesced registers, it is logical that noone will ever query > the liveness of those registers (unless there is a bug somewhere in the Indeed the coalesced registers may logically not be queried since they do not appear in any operand list of the machine code, but the VarInfo::DefInst in VirtRegInfo of the

One of my pass requires LiveIntervals to build the interference graph, because LiveVariables do not provide an interface to iterate through all viritual registers. But LiveIntervalAnalysis.h is not in "include/llvm/CodeGen", so I have to either include it by: #include "../../llvm/lib/CodeGen/LiveIntervalAnalysis.h" or point my project include path to

On Tue, 20 Sep 2005, Tzu-Chien Chiu wrote: > One of my pass requires LiveIntervals to build the interference graph, Ok. > because LiveVariables do not provide an interface to iterate through > all viritual registers. Ok, you could add a method to LiveVariables that returns VirtRegInfo.size(). The virtual registers are defined by the range: [MRegisterInfo::FirstVirtualRegister,

On 20/09/05, Chris Lattner <sabre at nondot.org> wrote: > > because LiveVariables do not provide an interface to iterate through > > all viritual registers. > > Ok, you could add a method to LiveVariables that returns > VirtRegInfo.size(). The virtual registers are defined by the range: > [MRegisterInfo::FirstVirtualRegister, >

Hi Fellows, I am writing a pass that requires the DominatorTree pass. In the runOnFunction of my own pass, I call llvm::SplitBlock to split a block (%for.end) at it's first insert point. Then, when I dump my dominator tree immediately after, I can see the newly split %for.end.split, but its DFSNumIn and DFSNumOut are not properly updated in llvm::SplitBlock (i.e., still the initialized

On Tue, 20 Sep 2005, Tzu-Chien Chiu wrote: > On 20/09/05, Chris Lattner <sabre at nondot.org> wrote: >>> because LiveVariables do not provide an interface to iterate through >>> all viritual registers. >> >> Ok, you could add a method to LiveVariables that returns >> VirtRegInfo.size(). The virtual registers are defined by the range: >>