similar to: [LLVMdev] [LLVMDev] [Modeling] About the structure of my allocator

Thank you! The pieces are starting to fall into place finally. I need to track which MachineBasicBlocks branch into other MachineBasicBlocks. How do I do it? I see a MachineOperand can hold a MachineBasicBlock*. Does this mean the instruction may branch to the MachineBasicBlock, or can it be something like an object reference? - Thanks, Jeff Kunkel On Thu, Sep 2, 2010 at 1:56 PM, Jeff Kunkel

On Sep 2, 2010, at 2:44 PMPDT, Jeff Kunkel wrote: > I need to track which MachineBasicBlocks branch into other > MachineBasicBlocks. How do I do it? Look at the Predecessor/Successor lists, which are target-independent > I see a MachineOperand can hold a MachineBasicBlock*. Does this mean > the instruction may branch to the MachineBasicBlock, or can it be > something like an

Is there any way to tell where in the Instruction list, the branch to the other MachineBasicBlock happens? I know in the BasicBlock had a nice api for it. Thanks, Jeff Kunkel On Thu, Sep 2, 2010 at 5:56 PM, Dale Johannesen <dalej at apple.com> wrote: > > On Sep 2, 2010, at 2:44 PMPDT, Jeff Kunkel wrote: > >> I need to track which MachineBasicBlocks branch into other

It is at the end allowing for oddities like debug info and multiple branches. You might want to look at AnalyzeBranch. On Sep 2, 2010, at 4:19 PMPDT, Jeff Kunkel wrote: > Is there any way to tell where in the Instruction list, the branch > to the other MachineBasicBlock happens? I know in the BasicBlock had > a nice api for it. > > Thanks, > Jeff Kunkel > > On Thu,

Would I be correct in assuming that the alias set is defined as the registers which may reside in the same space as the register? In other words the register is either a super or sub register which holds the same physical location in the register set? Could someone please explain what the Alias set is if it is not what I described above? TargetRegisterInfo::getAliasSet( unsigned reg ) Thanks

Also note: there may be multiple MachineBasicBlock's for a single BasicBlock. - David M On Fri, Oct 15, 2010 at 4:59 AM, Jeff Kunkel <jdkunk3 at gmail.com> wrote: > I don't think you can. > > The BasicBlock is a member of MachineBasicBlock. It is not inherited, > so it cannot be cast. The number of the MachineBasicBlock is not the > same as any BasicBlock values.

Is there an easy way to obtain all liveout variables of a basic block? Liveins can be found for each MachineBasicBlock, but I can only find liveouts for the whole function, at MachineRegisterInfo. Do I need to find them out manually?

Hello, we can get BasicBlock from MachineBasicBlock through MachineBasicBlock::getBasicBlock() function, but how can I get MachineBasicBlock of a BasicBlock? Thank you!

Perhaps what I think is a problem really is not a problem. So when a jump occurs from one block A to block B, then the registers are certain state, and register allocation happens with the initial state defined by A->B. When a third block C jumps to block B, the state of the registers are different. Thus register allocation needs to account for the jump from C->B, by a few ways: 1. The

I don't think you can. The BasicBlock is a member of MachineBasicBlock. It is not inherited, so it cannot be cast. The number of the MachineBasicBlock is not the same as any BasicBlock values. So MachineFunction::getMachineBasicBlock( BasicBlock::{get the number} ) cannot work. I do not see much in the basic block which can identify it. So you can search for it. typedef struct findBlock {

It would go something like like the code below. The goal would be to turn the basic blocks which the graph looks like "...->x->y->..." where the instructions of x and y could live in the same basic block without a jump or fall through in between. bool runOnMachineFunction(MachineFunction &mf) { BitVector seen( mf.size() ); for( unsigned i = 0, e = mf.size();

Thanks for the information. I still don't know how do I partition registers into different classes from the virtual registers? For instance, I have the function who which iterates over the instructions, but I don't know how to write the function which returns the different register class. void RAOptimal::Gather(MachineFunction &Fn) { // Gather just iterates over the blocks,

llvm::TargetRegisterClass::getSize() llvm::TargetRegisterClass::getAllignment() will return the size and alignment of a virtual register used both in register allocation and stack slot assignment. llvm::TargetRegisterClass::alloc_order_begin() llvm::TargetRegisterClass::alloc_order_end() will give a list of the possible physical registers. When a virtual register is assigned a physical register

Because I feel bad for giving a non-answer: An easy way to find if a virtual register is alive after the basic block is to While iterating over the virtual registers - Check to see if the virtual register's "next" value exists outside of the basic block. for instance: std::vector<unsigned> findLiveOut( MachineBasicBlock * mbb ) { std::vector<unsigned> liveout; for(

I have a live interval, and I would like to find out what SlotIndex the next use the register will occur? Is there any way to map a live interval back into instructions or SlotIndexes or blocks used by? - Thanks Jeff Kunkel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110120/fd429dbd/attachment.html>

I understand the mechanics. I don't know why a lesser weight is better than a greater weight. On Thu, Oct 28, 2010 at 7:22 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Oct 28, 2010, at 4:05 PM, Jeff Kunkel wrote: > >> I was studying the basic register allocator, and I am wondering why >> "LessSpillWeightPriority" priority was used over the

I am looking for the slot index of a register around the given slot index Min. Is there a better way than the linear search: ... findDefUsesAroundIndex( LiveInterval* li, SlotIndex Min ) ... for( MachineOperand * mo = MRI->getRegUseDefListHead(li->reg); mo; mo = mo->getNextOperandForReg() ) { SlotIndex si = SI->getInstructionIndex( use.getOperand().getParent() ); if(

Under what circumstances will a TerminatorInst will have multiple successors? The three methods: virtual BasicBlock *getSuccessorV(unsigned idx) const = 0; virtual unsigned getNumSuccessorsV() const = 0; virtual void setSuccessorV(unsigned idx, BasicBlock *B) = 0; are defined for the TerminatorInst class, but I cannot see why a terminator is allowed to go to different targets. Thanks,

I'm just running VS 10 in debug mode. In a step by step set up: 1. I download the svn 2. I make my changes 3. I compile the libraries 4. I make changes to the code within my project 5. I compile my code, and I re-link llc with my changed files. 6. I repeat 4,5, and 6 until it finally works. - Jeff Kunkel On Tue, Nov 2, 2010 at 1:21 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: >

Hello, does LLVM already have a Random Number Generator built into it's library somewhere? I know code generation is suppose to be deterministic, but when producing a random number can be deterministic if the random number generator is also deterministic. - Thanks - Jeff Kunkel