similar to: [LLVMdev] MachinePostDominator

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 {

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!

Hi, Just my two cents: If I recall correctly, in some papers on the linear scan register allocation people described that they tried different orderings for instruction numbering, e.g. including DFS or based on the loop nesting levels, etc. There was no clear winner though. But let's see the numbers anyway. May be it really brings some improvements. -Roman Chris Lattner wrote: > On

On 4/25/2013 12:06 PM, Giacomo Tagliabue wrote: > Thanks, > So, how do I check if a block dominates another one? In IR use analysis DominatorTree from "include/llvm/Analysis/Dominators.h". For machine instructions, use MachineDominatorTree from "include/llvm/CodeGen/MachineDominators.h". Both of them implement function "dominates" that takes two blocks

On Sep 5, 2013, at 5:15 PM, Ken Dyck <kd at kendyck.com> wrote: > Hi, > > One of the long-standing code clean-up bugs in Bugzilla is to extract > the Machine* code from the CodeGen library into a separate one, on > which CodeGen depends ( > http://llvm.org/bugs/show_bug.cgi?id=1121). > > I'd like to start working on this. The general approach I'm planning

Hi John. > I am putting this information > into my temp. wiki page in hopes of getting it into the dev wiki when > that is available. The dev wiki is up at its temporary name http://google2.osuosl.org/wiki/. Feel free to dump your stuff on there. On Fri, Mar 13, 2009 at 7:43 PM, John Mosby <ojomojo at gmail.com> wrote: > Hi Evan, > Thanks very much for the review, I am

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

Thanks! I checked that module. If I use dominates(const Instruction *Def,const Instruction *User) it will automatically check everything, so I don't have to handle the case with instructions in the same BB, right? Thanks, GT On 25 April 2013 12:17, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 4/25/2013 12:06 PM, Giacomo Tagliabue wrote: > >> Thanks,

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

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

Hi Evan, Thanks very much for the review, I am implementing your suggestions today and will have the next patch together this weekend. A few questions/comments: On Thu, Mar 12, 2009 at 10:05 AM, Evan Cheng <echeng at apple.com> wrote: > > 1. Some of the functions that you introduced, e.g. stringifyCSRegSet > probably ought to be "static" and ifdef'ed out when NDEBUG

Hi, This pass is similar to the one in BreakCriticalEdges.cpp, but it works for MachineFunction's, instead of Functions. The existence of critical edges complicates many optimizations. When doing register allocation, you don't necessarily have to remove critical edges (you can use conventional SSA-form, for instance. See "Translating Out of Static Single Assignment Form. SAS

Hi, guys, what is the interface for finding the immediate dominator of a machine basic block in LLVM 2.1? I found some methods to check if a node dominates other in llvm::MachineDominatorTree, but I was looking for something like: MachineBasicBlock * mbb = ... MachineBasicBlock * iDom = XXX->getImmediateDominator(mbb); is there something similar? best, Fernando

Tom, I think it might be productive to fork this thread to discuss making the requirements for upstreaming a new LLVM target more explicit and open. I'd also like to gauge interest in an idea I've discussed privately with a few community members, namely the concept of having a semi-official "incubation" system whereby proposed backends could get a trial run before becoming part

Thanks, So, how do I check if a block dominates another one? On 25 April 2013 11:59, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 4/25/2013 11:52 AM, Giacomo Tagliabue wrote: > >> Is there an easy way to know if, at a certain instruction, a certain >> value is usable or not? i.e., I am sure that if i use that value i don't >> to get the error

Hi, One of the long-standing code clean-up bugs in Bugzilla is to extract the Machine* code from the CodeGen library into a separate one, on which CodeGen depends ( http://llvm.org/bugs/show_bug.cgi?id=1121). I'd like to start working on this. The general approach I'm planning to take is: 1. Identify which code to move. 2. Eliminate all dependencies that the Machine code has on the

Hi John, It looks pretty good. Thanks for working on this. Some comments: 1. Some of the functions that you introduced, e.g. stringifyCSRegSet probably ought to be "static" and ifdef'ed out when NDEBUG is defined. 2. + // DEBUG + if (! MBB->empty() && ! CSRUsed[MBB].intersects(restore)) { + MachineInstr* MI = BeforeI; + DOUT <<

On Wed, Sep 11, 2013 at 12:29 AM, Andrew Trick <atrick at apple.com> wrote: > > If that is the goal, then you only want the modules for Machine IR, and maybe some core analysis passes. The “Machine” modules you listed above include machine code analysis or transform passes that you probably don’t want. Pruning the list to basic IR support: > >> - MachineBasicBlock >> -

Hi, I have ported LLC to a risc cpu. It can pass benchmark that I have at current. But I want do some optimization after register alloction by adjusting register using. I scan MachineBasicBlock to analyze operand's IsKill, IsDead , IsDef attribute to get a physical register's liverange. But I get a strange case at MBB.jpg. R4 is marked <kill> at MBB0. If I scan R4's