search for: mbbs

...ond; assert(inserted && "multiple MachineInstr -> index mappings"); i2miMap_.push_back(I); MIIndex += InstrSlots::NUM; } // Set the MBB2IdxMap entry for this MBB. MBB2IdxMap[MBB->getNumber()] = std::make_pair(StartIdx, MIIndex - 1); For empty MBBs, the last line would create a pair, where the end element is smaller than the start element, which is a bit counter-intuitive. This may lead to some assertion failures in other parts of the code generator, if they use MBB2IdxMap for checking is an instruction belongs to a given MBB. Question: Is...

...ass. However, with the current system there are several challenges ahead. The most important is that the CFG is not preserved during several passes including code-gen-prepare, cfg-simplify, remove-unreachable-blocks, tail-merge, and tail-duplication. So in order to keep track of the mapping between MBBs and BBs, one needs to insert code in every function that modifies the structure of BBs and MBBs. The current block placement pass (MachineBasicBlockPlacement) works at the machine code level and with the new profiling structure (SampleProfileLoader), is effective as far as context-free profiling i...

On Jan 23, 2013, at 12:36 PM, Stefan Hepp <stefan at stefant.org> wrote: > However, an alternative option could be to simply disallow different edge weights for edges with the same source and destination, or to make the call to getEdgeFreq(Pred,BB) in BlockFrequencyImpl distinguish between the edges, which would eliminate the need for an additional PtrSet, but is not that easy to

Hi, On 01/23/2013 11:30 PM, Jakob Stoklund Olesen wrote: > If you can find the place that creates the duplicate MBB edge, that would be great. > Found it :) It happens in lib/CodeGen/IfConversion.cpp at the very end in MergeBlocks. I attached a small patch that should resolve that issue. Our tests now compile sucessfully even without my previous patch. regards, Stefan --------------

I guess isUnpredicatedTerminator() and friends would just return false, but maybe there should be an assertion in an earlier pass that all instructions in the tail position of basic blocks really are terminators, or is that not required? // A On 9/29/07, Evan Cheng <evan.cheng at apple.com> wrote: > Yeah, that will cause problems. However, I expect an assertion > somewhere. Any

Yeah, that will cause problems. However, I expect an assertion somewhere. Any chance you can track down the exact problem? Thanks. Evan On Sep 28, 2007, at 1:37 PM, Andreas Fredriksson <deplinenoise at gmail.com> wrote: > Replying to my self here. It seems I was missing an isTerminator = 1 > on the branch instruction in question, so LLVM didn't know that the >

On Fri, 2004-07-09 at 05:02, Vladimir Prus wrote: > I've just spend some time looking at the above function, and while I > understood what it does, a comment would have helped a lot. Thanks for bringing this to my attention! > Maybe, something like: > > // Determine the end of the live interval for this register > // For physical register, all internvals are within basic

...ation and BranchFolding passes. While these two are technically not part of the superblock definition, they are usually part of a superblock implementation because you want a superblock to be as big as possible. Of course, you could make a big superblock in the CFG and then tile it down into basic MBBs. But the only reason that I can think of for that would be codegen simplicity and with GlobalISel, I would think that would no longer be the case. Anyways, am I getting this right? If so, is there any way to control the creation of these superblocks, that is, which basic blocks from the CFG go int...

On Oct 18, 2011, at 5:22 PM, Chandler Carruth wrote: >> As for why it should be an IR pass, mostly because once the selection dag runs through the code, we can never recover all of the freedom we have at the IR level. To start with, splicing MBBs around requires known about the terminators (which we only some of the time do), and it requires re-writing them a touch to account for the different fall-through pattern. To make matters worse, at this point we don't have the nicely analyzable 'switch' terminator (I think), and so the...

Replying to my self here. It seems I was missing an isTerminator = 1 on the branch instruction in question, so LLVM didn't know that the instruction terminated a basic block. Does that make sense, or is just masking some other problem? Thanks, Andreas On 9/28/07, Andreas Fredriksson <deplinenoise at gmail.com> wrote: > Hi, > I'm trying to write up my little m68k backend

...d at 2pi.dk>wrote: > > On Oct 18, 2011, at 5:22 PM, Chandler Carruth wrote: > > As for why it should be an IR pass, mostly because once the selection dag >> runs through the code, we can never recover all of the freedom we have at >> the IR level. To start with, splicing MBBs around requires known about the >> terminators (which we only some of the time do), and it requires re-writing >> them a touch to account for the different fall-through pattern. To make >> matters worse, at this point we don't have the nicely analyzable 'switch' >&g...

We are developing a new backend for a custom processor using LLVM. After updating to LLVM 3.2, we run into an assertion in BlockFrequencyImpl.h. The offending test-case looks basically like this: for ( ... ) { switch (i) { case 100: // do something break; case 102: // do something else break; case 103: // do some more break; case 104: // now something different

...a soon) seem to indicate that just giving a baseline ordering of block to the CodeGen layer > > As for why it should be an IR pass, mostly because once the selection dag > runs through the code, we can never recover all of the freedom we have at > the IR level. To start with, splicing MBBs around requires known about the > terminators (which we only some of the time do), and it requires re-writing > them a touch to account for the different fall-through pattern. To make > matters worse, at this point we don't have the nicely analyzable 'switch' > terminator (I...

I've just spend some time looking at the above function, and while I understood what it does, a comment would have helped a lot. Maybe, something like: // Determine the end of the live interval for this register // For physical register, all internvals are within basic blocks so // we look for the instruction in this basic block which last uses it. The first loop might have a comment like:

For nefarious reasons I won't go into (this is for a quick hack that will be thrown away in a week or two), I'd like my Asm printer to get MBBs in a depth first order. Is there an existing pass or function that will let me do this easily? Thanks, Dan

Hi I'm seeing something probably related to this. I'm getting an assert from the lower_bound in LiveIntervals::findLiveinMBBs (from a checking std:: VS2005 implementation). Idx2MBBMap has two elements in it, both of which have a .first of 0. (I believe because of an empty MBB in the function below, so StartIndex doesn't advance). scott On Wed, Apr 16, 2008 at 2:52 AM, Roman Levenstein <romixlev at yahoo.com> w...

...on't forget? I'm a little occupied right now. But I'll take care of this soon. Evan On Apr 16, 2008, at 10:52 AM, Scott Graham wrote: > Hi > > I'm seeing something probably related to this. I'm getting an assert > from the lower_bound in LiveIntervals::findLiveinMBBs (from a checking > std:: VS2005 implementation). Idx2MBBMap has two elements in it, both > of which have a .first of 0. (I believe because of an empty MBB in the > function below, so StartIndex doesn't advance). > > scott > > On Wed, Apr 16, 2008 at 2:52 AM, Roman Levenstei...

Hi, I'm trying to write up my little m68k backend things have been going smoothly. I've been working with the x86 backend as a template, fixing things as I go. Now I've run into branches and I have a crash I don't really understand. Here's the sample IR I'm running llc on to generate assembly: define i32 @ilog2(i32 %x) { entry: %tmp718 = icmp eq i32 %x, 0

...t;> >> On Oct 18, 2011, at 5:22 PM, Chandler Carruth wrote: >> >> As for why it should be an IR pass, mostly because once the selection >>> dag runs through the code, we can never recover all of the freedom we have >>> at the IR level. To start with, splicing MBBs around requires known about >>> the terminators (which we only some of the time do), and it requires >>> re-writing them a touch to account for the different fall-through pattern. >>> To make matters worse, at this point we don't have the nicely analyzable >>&gt...

Hello, I was looking at how the memory for MachineBasicBlocks is managed and something seems strange. On one hand, a MachineFunction uses a recycling allocator to create and destroy MBBs without costly heap allocation (the same is done for MachineInstrs, MachineOperands, etc.). On the other hand, each MBB also has a number of STL vectors within it. For example, for Predecessors, Successors, Weights, LiveIns. Maintaining these vectors involves heap allocation and they don't hav...