similar to: Help in understanding physreg LiveVariables

<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" >Matthias,</div> <div dir="ltr" > </div> <div dir="ltr" >Thanks for the response.</div> <div

So if I create a value with a DAG.getUndef(myVT); call during instruction legalization, how can I access that value as input in another BB/DAG (also during instruction legalization) without worrying about live-ins and/or phi nodes? Can I create a single virtual register and build both a CopyToReg and a CopyFromReg node with it? I assumed that would break SSA. Perhaps I should have said that what

So if I first create the value in an entry BB and then build a CopyToReg but then I have to read it in a BB that loops back to itself, with it's own CopyToReg at the end, then I have two CopyToReg nodes for the same value. In this case, I need to create 3 virt regs, 1 for each CopyToReg and a third for the CopyFromReg in the beginning of the loop BB, right? And then I need to build a PHI

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

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

Dear LLVM guys, I am coding a liveness analysis algorithm, and I found this comment on LiveVariables.cpp: Line 00195 - http://llvm.org/doxygen/LiveVariables_8cpp-source.html : // PhysRegInfo - Keep track of which instruction was the last use of a // physical register. This is a purely local property, because all physical // register references as presumed dead across basic blocks.

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

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

Hi Quentin, MyInst is a custom instruction that has implicit-defs of fixed registers. The implicit-defs are seen at the end of Instruction Selection. I'd like to add a report, but I am working on an out-of-tree backend based on 7.0. I can try to help reduce the testcase down. Filed https://bugs.llvm.org/show_bug.cgi?id=41790 Regards, Kevin On 2019-05-07 3:45 p.m., Quentin Colombet wrote:

On Thu, 7 Jun 2012 22:14:00 -0700 Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jun 7, 2012, at 7:31 PM, Hal Finkel wrote: > > > 112B BB#1: derived from LLVM BB %for.body, ADDRESS TAKEN > > Predecessors according to CFG: BB#0 BB#1 > > %vreg12<def> = PHI %vreg13, <BB#1>, %vreg11, > >

On Jun 7, 2012, at 10:54 PM, Hal Finkel wrote: > For example, sometimes LiveIntervals asserts with: > register: > %CTR8 > clang: /llvm-trunk/lib/CodeGen/LiveIntervalAnalysis.cpp:446: > void llvm::LiveInterval > s::handlePhysicalRegisterDef(llvm::MachineBasicBlock*, > llvm::MachineBasicBlock::iterator, llvm::SlotIndex, > llvm::MachineOperand&,

Hey all, I've found a bug in either the PBQP register allocator or in VirtRegRewriter. I'm observing this assertion in VirtRegRewriter::rewrite() fail: unsigned VirtReg = MO.getReg(); unsigned PhysReg = VRM->getPhys(VirtReg); ... assert(!MRI->isReserved(PhysReg) && "Reserved register assignment"); Indeed there is a case where

> The best fix is to teach this scheduler how to deal with these > dependencies. :-) > > If you just want a check, I think it's easier to just check register > class's copy cost. -1 means it's extremely expensive to copy registers > in the particular register class. Evan, I am not sure what you mean by "if you just want a check" - I was trying to point out

Hi, I have cases of instruction pairs, where one is cheaper 2-address, and the other 3-address. I would like to select the 2-addr instruction during isel, but use the 3-addr instruction to avoid a copy if possible. I find that TwoAddressInstructionPass::isProfitableToConv3Addr() is only checking for the case of a physreg copy, and so leaves the majority of cases as they are (2-address). I

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

Hi, I just switched to the 2.5 release branch and noticed that llc runs into the following assert in ScheduleDAGList::ScheduleNodeTopDown() using our custom backend: assert(!I->isAssignedRegDep() && "The list-td scheduler doesn't yet support physreg dependencies!"); It turns out that the register dependency concerns the condition code register which is

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

Hello all Currently I want to use the accurate liveness information when writing a *target independent* FunctionPass based on LLVM. The one I can find is LiveValues, a FunctionPass. But it doesn't use classic dataflow equation and can only provide approximate and conservative result. The another one is LiveVariables which use classic data flow equation, but it comes from Clang's analysis

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. I don't see any easy solution to reduce memory usage, but should we optimize such a huge function at once? If the function is over some reasonable limit (5k

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.