search for: addlivein

...s to the MBB::LiveIn list isn't being respected. Could we add an assertion to check for it? ==== //dwarc/Tools/MetaWare/Toolset/main/dev/llvm/include/llvm/CodeGen/MachineBasicBlock.h#6 - /remote/arctools/marksl/marksl_1/llvm/include/llvm/CodeGen/MachineBasicBlock.h ==== 295,298d294 < /// addLiveIn - Add the specified register as a live in. Note that it < /// is an error to add the same register to the same set more than once. < void addLiveIn(unsigned Reg) { LiveIns.push_back(Reg); } < 306a303,310 > /// addLiveIn - Add the specified register as a live in. Note that it &g...

...dNode, 1)) > in the RDMSR node. > 2. Give your RDMSR node type MVT::Glue instead of MVT::Other I tried doing what you said, and the DAG looks like how I think it supposed to look like (attached the picture below). if(Subtarget->is64Bit()) { idReg = X86::RCX; resultReg = MF.addLiveIn(X86::RAX, &X86::GR64RegClass); } else { idReg = X86::ECX; resultReg = MF.addLiveIn(X86::EAX, &X86::GR32RegClass); } idRegValue = CurDAG->getRegister(idReg, resultType); SDValue setIdNode = CurDAG->getCopyToReg(CurDAG->getEntryNode(), dl, idRegValue, id,...

...*DAG.getContext()); CCInfo.AnalyzeFormalArguments(Ins, CC_FOO); for (auto &VA : ArgLocs) { if (VA.isRegLoc()) { // Arguments passed in registers EVT RegVT = VA.getLocVT(); const unsigned VReg = RegInfo.createVirtualRegister(&FOO::PRegsRegClass); RegInfo.addLiveIn(VA.getLocReg(), VReg); SDValue ArgIn = DAG.getCopyFromReg(Chain, dl, VReg, RegVT); InVals.push_back(ArgIn); continue; } // assume the parameter registers are enough, no need to store in frame right now } return Chain; } In the above function, CC_FOO is defined in Cal...

...e where they are intentional. The important thing would be to add something like MachineRegisterInfo::setVirtRegsAfterRegalloc() and MachineRegisterInfo::getVirtRegsAfterRegalloc(). Because I would assume that we will find more examples like the following (from MachineBasicBlock): > > void addLiveIn(MCPhysReg PhysReg, LaneBitmask LaneMask = ~0u) { > LiveIns.push_back(RegisterMaskPair(PhysReg, LaneMask)); > } > > this needs to be changed to support VRegs. But if we do that change, I'd like to change it to something like this: > > void addLiveIn(unsigned Reg, Lane...

...ss to other register class. I implement it in LowerFormalArguments() like this: .... for (auto &VA : ArgLocs) { if (VA.isRegLoc()) { // Arguments passed in registers EVT RegVT = VA.getLocVT(); VReg = RegInfo.createVirtualRegister(&FOO::BRegsRegClass); RegInfo.addLiveIn(VA.getLocReg(), VReg); SDValue ArgIn = DAG.getCopyFromReg(Chain, dl, VReg, RegVT); SDValue ArgIn_copy = DAG.getNode(FOOISD::MOVE_FLAG , dl, MVT::i32, Chain, ArgIn); // this node is added in order to move the value from BRegs class to ARegs class and I want it be kept even it is not used...

I tried using this flag and it gave me errors on code that otherwise assembles and runs just fine (using the version of Gcra.cpp that Lang wrote). So I'm wondering if I should really be using the flag? I'm using it like this: llc -verify-machineinstrs -load Debug/lib/P4.so -regalloc=gc xxx.bc Susan On 11/15/2012 01:13 PM, Jakob Stoklund Olesen wrote: > > On Nov 15, 2012, at

Hi Susan, Jakob pointed out to me that the Gcra.cpp allocator doesn't record basic-block live-ins, which are used by the verifier to check correctness. You can record which variables are live into a basic block with MachineBasicBlock::addLiveIn(unsigned physReg). I don't know the verifier well, but if it's using other built in infrastructure for register allocation then it may not be a good fit for your allocator. I'll try to find time to look at the example files you sent in the next couple of days. Cheers, Lang. On Thu,...

Hey, I wanted to add an intrinsics to read MSRs. So I added the intrinsics and lowered it to a new ISD node I created ISD::RDMSR, its first operand is the MSR id. I added a case in X86DAGToDAGISel::Select for ISD::RDMSR. Now I know rdmsr works like so: mov r/ecx, <id> rdmsr r/eax holds the lower 32/64 bit >From what I understood this needs a Token Factor node, nodes which are

...e basic block? Is it true that APSR is never assumed to live across basic block boundaries? Thank you! Ming Zhang >On Aug 2, 2017, at 9:07 AM, Matthias Braun via llvm-dev llvm-dev at lists.llvm.org llvm-dev at lists.llvm.org>> wrote: >Yes LivePhysRegs can do that for you. It has addLiveIns() and addLiveOuts() functions to get the live-in or live-out set for a basic block (make the set is empty when you call these functions). >Yes APSR is marked as a reserved register by the ARM target, this means we do not track liveness for it. >- Matthias >>On Aug 2, 2017, at 2:45 A...

...rator I = cur.begin(), E = cur.end(); I != E; ++I) { const LiveRange &LR = *I; if (li_->findLiveInMBBs(LR.start, LR.end, LiveInMBBs)) { for (unsigned i = 0, e = LiveInMBBs.size(); i != e; ++i) if (LiveInMBBs[i] != EntryMBB) LiveInMBBs[i]->addLiveIn(Reg); LiveInMBBs.clear(); } } } If it is the case, it is OK. It was not clear for me that one has to do it in the regalloc. My assumption was that VRM would do it. Thanks a lot, Roman

...machine specific registers. My solution I found is based to the RegInfo.setSimpleHint() API. Here is the body of the parameters loop of TargetLowering::LowerFormalArguments VReg = RegInfo.createVirtualRegister(RC); RegInfo.setSimpleHint(VReg,CLP::FA_ROFF1+i); RegInfo.addLiveIn(CLP::FA_ROFF1+i, VReg); Load = DAG.getCopyFromReg(Chain, Loc, VReg, ValVT.getSimpleVT().SimpleTy); Thanks again for your support, Dominique T. -----Original Message----- From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Krzysztof Parzyszek via llvm-dev Sent: lundi 2...

...v> <div dir="ltr" > </div> <div dir="ltr" >If it's assumed that allocatable (and unreserved) PhysRegs are only live within a basic block, why is it possible to add such a physreg as an MBB live-in? Should there be an assertion added to MachineBasicBlock::addLiveIn() ?</div> <div dir="ltr" > </div> <div dir="ltr" >Tyler</div> <div dir="ltr" > </div> <div dir="ltr" > </div> <blockquote data-history-content-modified="1" dir="ltr" style="bord...

...sh_back(DAG.getStore(Chain, dl, Arg, PtrOff, MachinePointerInfo(),false, false, 0)); } ... [2]: LowerFormalArguments ... if (VA.isRegLoc()) { // Arguments passed in registers. const TargetRegisterClass *RC = ARC::CPURegsRegisterClass; unsigned int Register = MF.addLiveIn(VA.getLocReg(), RC); EVT RegisterValueType = VA.getLocVT(); ArgValue = DAG.getCopyFromReg(Chain, dl, Register, RegisterValueType); InVals.push_back(ArgValue); } else { // Sanity check assert(VA.isMemLoc()); // Load the argument to a virtual register u...

Hi I find various argument lowering functions that add registers to function live in do the following args_float[ArgNo] = AddLiveIn(MF, args_float[ArgNo], &Alpha::F4RCRegClass); Do these live in registers get used later during liveness analysis/register allocation ? How can I verify if it has indeed impacted the live intervals? thanks shrey

...:04 PM, Lang Hames <lhames at gmail.com> wrote: > Jakob pointed out to me that the Gcra.cpp allocator doesn't record basic-block live-ins, which are used by the verifier to check correctness. > > You can record which variables are live into a basic block with MachineBasicBlock::addLiveIn(unsigned physReg). I don't know the verifier well, but if it's using other built in infrastructure for register allocation then it may not be a good fit for your allocator. To clarify, the live-in lists are not there for the verifier's benefit. They are used by various post-RA passes t...

Hi all, Our target does not have native support for 64-bit integers, so we rely on library calls for certain operations (like sdiv). We recently ran into a problem where these operations that are expanded to library calls aren't maintaining the proper ordering in relation to other chains in the DAG. The following snippet of a DAG demonstrates the problem. t0: ch = EntryToken t2:

Here are 2 patches, which are independent of each other. The first splits PrologEpilogInserter into 2 parts : http://reviews.llvm.org/D16481 After looking at the code I thought it made more sense for the major split to include whether callee-saved register spills are supported. So for non-virtual targets, virtual registers are not supported and scavenging is optionally supported, and vice versa

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,

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]

...nd ensure the proper phi nodes get updated/created). If it's assumed that allocatable (and unreserved) PhysRegs are only live within a basic block, why is it possible to add such a physreg as an MBB live-in? Should there be an assertion added to MachineBasicBlock::addLiveIn() ? You should not need to worry about live-ins, they are only assumed to complete after register allocation. The only exception to this rule is the exception value on the edge to a landing part being marked as live-in and the per-function live-ins for arguments, but you should not need to worry ab...