search for: machinebasicblocks

...trary instruction just before the position of a MachineBasicBlock::iterator. After the BuildMI function, is the MachineBasicBlock::iterator still valid? What if I want to insert an instruction before the newly added instruction? How should I do that? Some general questions: Why are there multiple MachineBasicBlocks per BasicBlock? What is the motivation behind this representation? Is there any example in the codebase of doing the above? Thanks, -- View this message in context: http://www.nabble.com/Inserting-MachineBasicBlock%28s%29-before-a-MachineBasicBlock-tp19746986p19746986.html Sent from the LLVM -...

I would like to make a suggestion. In the LiveIntervalAnalysis class, instead of numbering the instructions in the order in which basic blocks are stored in the machine function, use the df_ext_iterator. It will order the instruction according to the dominance tree (or it seems to be doing so). There are many advantages in doing this. One of them is that, once you traverse the dominance tree

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.

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

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 {

> If you don't want critical edges in the machine code CFG, you're going to > have to write a machine code CFG critical edge splitting pass: LLVM > doesn't currently have one. > > -Chris Hey guys, I've coded a pass to break the critical edges of the machine control flow graph. The program works fine, but I am sure it is not the right way of implementing it.

On Thu, 21 Jun 2007, Fernando Magno Quintao Pereira wrote: > I would like to make a suggestion. In the LiveIntervalAnalysis class, > instead of numbering the instructions in the order in which basic blocks > are stored in the machine function, use the df_ext_iterator. It will order > the instruction according to the dominance tree (or it seems to be doing > so). There are many

Nice idea. Please also try using SmallPtrSet (with a sufficiently large size) instead of std::set for traversal after everything is working. Using std::set can really hurt compile time in case of large basic block numbers. Is there a way to dynamically adjust "SmallSize" based on number of basic blocks in the function? Evan On Jun 21, 2007, at 10:20 PM, Fernando Magno Quintao

On Tue, 4 Jul 2006, Fernando Magno Quintao Pereira wrote: > However, it does not remove all the critical edges. I am getting a very > weird dataflow graph (even without the Break Critical edges pass). The > dataflow generated by MachineFunction::dump() for the program below is > given here: > http://compilers.cs.ucla.edu/fernando/projects/soc/images/loop_no_crit2.pdf ... > The

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 li...

The attached patch fixes bugs related to MachineBasicBlock::iterator. I don't have any test cases that reproduce on an X86 machine the problems that this patch fixes (these bugs were found when make check was run on a mips board). Please review. The first part just ensures that iterator I is not instr_end() before it invokes isInsideBundle(). The second part changes the signature of spillAll

...a lot Jeff. I changed the setNumber function call to MBB->setNumber(mf->addToMBBNumbering(MBB)); But it still enters the infinite loop. It is strange that if I insert all these instructions into an existing MachineBasicBlock, the error disappears. It is due to the way I create or insert MachineBasicBlocks in a wrong way. When each operand is added to an instruction, the use/def list for the function will be updated. It should not happen that an MachineOperand.Contents.Reg.Next points to itself. Anyway, thanks a lot again for your reply. ~Bin On 10/20/2010 3:53 PM, Jeff Kunkel wrote: > From...

Hi all, I think that I came somewhat closer to a solution for splitting a MachineBasicBlock for a PSEUDO_CALL_R instruction and having a label to the new MBB: For following piece of code: --- typedef int callme_t(int a, int b); callme_t* c01; int foo(int a, int b) { return c01(a,b); // MachineBasicBlock will be split at call instruction } --- I have initially following correspondence: BB1

Hi, EveryOne: I am travelling CFG with MachineFunction. So I want to sure it. (Preccessors' Number) < MachineBasicBlock's Number < (Successors's Number), Is it really? best regards. ___________________________________________________________ 好玩贺卡等你发，邮箱贺卡全新上线！ http://card.mail.cn.yahoo.com/ -------------- next part -------------- An HTML attachment was scrubbed...

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

Some stuff did not get pasted in properly. static MachineBasicBlock* ExpandCondMov(MachineInstr *MI, MachineBasicBlock *BB, DebugLoc dl, const MipsSubtarget *Subtarget, const TargetInstrInfo *TII, bool isFPCmp, unsigned Opc) { //

Thank you for your reply! > Every MachineBasicBlock has a list of successors; you can access it with > the successors() accessor. That's what you should be using for any CFG > analysis. I am aware of these methods of class MachineBasicBlock, which allows one to access a MachineBasicBlock's successors and predecessors in the CFG. But the CFG itself may no longer be valid if a

Can you please post the code to split a MachineBasicBlock? I am trying to split a MachineBasicBlock at a specific instruction in the MBB, let us say, into MBB1 and MBB2. This instruction should go into MBB2. Also MBB1 should have an unconditional branch to MBB2 as the terminator. (quite similar to splitBasicBlock in BasicBlock.cpp) Meanwhile, I am trying to come up with a variant of

Hi all, While I using BuildMI with MachineBasicBlock as parameter, I made a mistake. The mistake was that the MachineBasicBlock of instruction, which is for insertion, is different with given MachineBasicBlock as parameter. I have thought if there is assertion code to check whether MachineBasicBlocks are same between instruction's MachineBasicBlock and given MachineBasicBlock as parameter or not, it might be so useful to find wrong code. How do you feel about this? Is it useful or not? In order to do this, I have attached a simple patch. If there is something wrong, please let me know....

Hi all, Two days ago MachineBasicBlock got ilistified. What does this mean and how does it affect you? Read on. MachineBasicBlock used to have a std::vector<MachineInstr*> to represent the instructions it constisted of. This representation has the following problems: 1) O(n) insertions/removals to/from anywhere but the end of a basic block (removals are very comomn in peephole