search for: branchfolding

I've ran across an issue in BranchFolding.cpp where it is incorrectly folding a branch to the wrong fallthrough location. This is in LLVM 2.4 and seems to be in 2.5 also. The code in question is: void BranchFolder::OptimizeBlock(MachineBasicBlock *MBB) { MachineFunction::iterator FallThrough = MBB; ++FallThrough; // If this...

Hi all, I updated from 2.2 to the latest SVN head and I now get a debug assert in BranchFolder::RemoveBlocksWithHash: "vector iterators incompatible". I'm using Visual C++ 2005. I think this is the culprit code: MergePotentials.erase(CurMPIter); if (CurMPIter==B) break; The erase clears the _Mycont field (i.e. the iterator's container), while the ==

On May 23, 2008, at 4:10 AM, Nicolas Capens wrote: > Hi all, > > I updated from 2.2 to the latest SVN head and I now get a debug > assert in BranchFolder::RemoveBlocksWithHash: “vector iterators > incompatible”. I’m using Visual C++ 2005. I think this is the > culprit code: > > MergePotentials.erase(CurMPIter); > if (CurMPIter==B) > break; >

Hi everyone, The code layout that TailMerging (inside BranchFolding) works on is not the final layout optimized based on the branch probability. Generally, after BlockPlacement, many new merging opportunities emerge. I did an experiment of adding additional BranchFolding and BlockPlacement after the existing BlockPlacement (i.e., -block-placement -branch-fold...

...ore 2 into %struct.2) STORE ... :: (store 2 into %struct + 2), (store 2 into %struct.2 + 2) and then MachineInstr::mayAlias fail to detect the stores as not aliasing. Without knowing how to interpret the situation with multiple MachineMemOperands I guess it is hard to improve the analysis. Maybe BranchFolding could do something better here (is it a bug to add multiple operands like this?). Regards, Björn

According to the docs, InsertBranch should only be called if AnalyzeBranch returns success. But in targets (like ARM or Sparc) that don't implement them, the following test fails: ----------------------------------- void %__gcov_init() { entry: switch uint 0, label %cond_true.i [ uint 0, label %UnifiedReturnBlock uint 875573313, label

On May 23, 2008, at 10:19 AM, Dale Johannesen wrote: > On May 23, 2008, at 4:10 AM, Nicolas Capens wrote: > >> I updated from 2.2 to the latest SVN head and I now get a debug >> assert in BranchFolder::RemoveBlocksWithHash: “vector iterators >> incompatible”. I’m using Visual C++ 2005. I think this is the >> culprit code: >> >>

Begin forwarded message: > > Increase default setting of tail-merge-threshold to > 150, based on llvm-test measurements. > > static cl::opt<unsigned> > TailMergeThreshold("tail-merge-threshold", > cl::desc("Max number of predecessors to consider tail > merging"), > - cl::init(100), cl::Hidden); > + cl::init(150),

On May 27, 2008, at 1:40 PM, Mike Stump wrote: > On May 23, 2008, at 10:19 AM, Dale Johannesen wrote: >> On May 23, 2008, at 4:10 AM, Nicolas Capens wrote: >> I also am not a STL guru; the standard says erase >> "Invalidates all the iterators and references after the point of the >> erase" >> which is not wonderfully worded, but I take it to mean an

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();

On May 27, 2008, at 2:01 PM, Dale Johannesen wrote: > On May 27, 2008, at 1:40 PM, Mike Stump wrote: >> >> From n2461: >> >>> 8 The insert members shall not affect the validity of iterators and >>> references to the container, and the erase members shall invalidate >>> only iterators and references to the erased elements. >> >> Pretty

...m/CodeGen/MachineBasicBlock.h:480 #12 0x08593f60 in llvm::ADRESInstrInfo::RemoveBranch (this=0x92cf50c, MBB=...) at /work/llvm/trunk/llvm/lib/Target/ADRES/ADRESInstrInfo.cpp:364 #13 0x0892d513 in llvm::BranchFolder::OptimizeBlock (this=0xbfffea70, MBB=0x931bd14) at /work/llvm/trunk/llvm/lib/CodeGen/BranchFolding.cpp:1200 #14 0x0892c565 in llvm::BranchFolder::OptimizeBranches (this=0xbfffea70, MF=...) at /work/llvm/trunk/llvm/lib/CodeGen/BranchFolding.cpp:972 #15 0x089298c2 in llvm::BranchFolder::OptimizeFunction (this=0xbfffea70, MF=..., tii=0x92cf50c, tri=0x92cf528, mmi=0x92f1228) at /work/llvm/trunk/llvm...

Hi Andrew, > No. Duncan suggested that he could hitch a ride with us through France. The problem is, we're not driving to Spain at all and there doesn't appear to be any place to transfer. > > The point is, you're not going to be able to leverage most of a CFG-based optimizing compiler if don't use the CFG to express control flow. when Chris first came up with his

...0.2429 ( 55.4%) 2.9804 ( 34.3%) 2.9815 ( 34.3%) X86 DAG->DAG Instruction Selection 1.8160 ( 22.0%) 0.0093 ( 2.1%) 1.8252 ( 21.0%) 1.8250 ( 21.0%) Loop Strength Reduction 0.8806 ( 10.7%) 0.0653 ( 14.9%) 0.9459 ( 10.9%) 0.9461 ( 10.9%) Greedy Register Allocator 1219 branchfolding - Number of block tails merged 1687 branchfolding - Number of branches optimized 1847 branchfolding - Number of dead blocks removed ** lencod split blocks at calls Program | GCCAS Bytecode LLC compile LLC-BETA compile JIT codegen | GCC CBE LLC LLC-BETA JIT | GCC/CBE GCC/LLC GCC/...

I think what's happening is BranchFolder::MaintainLiveIns is using a forward analysis on top of these missing kill flags, and updating the BB-live-ins/live-outs with an incorrect set of registers. Then when the stackmaps liveness analysis happens, it's not doing anything wrong, but it starts with the wrong set of live registers and will propagate those to the point of the

...- Number of emitted assembler fragments - total 22267993 assembler - Number of emitted object file bytes 1083677 assembler - Number of evaluated fixups 648094 assembler - Number of fragment layouts 41654 assembler - Number of relaxed instructions 2345 branchfolding - Number of block tails merged 687 branchfolding - Number of branches optimized 1047 branchfolding - Number of dead blocks removed 281 branchfolding - Number of times common instructions are hoisted 8002 codegen-dce - Number of dead instructions deleted...

Dan: CellSPU could clearly benefit from the post-RA scheduler. In fact, we were thinking about writing a machine pass of our own. One thing that does "disturb" me is that both HazardRecognizer and post-RA sched assume there's only one kind of NOP. For Cell, there are two, depending upon the pipeline being filled. Pipe 0 takes "ENOP" whereas Pipe 1 take

I forgot to CC the forum. I found what was happening. The BranchFolder documentation says: // Note that this pass must be run after register allocation, it cannot handle // SSA form. > On Wed, Oct 6, 2010 at 8:05 PM, Jeff Kunkel <jdkunk3 at gmail.com> wrote: >> No, I just noticed that blocks were separated. >> >> >> On Wed, Oct 6, 2010 at 8:04 PM, Bob Wilson

On 9/27/19 7:33 AM, Matt Arsenault via llvm-dev wrote: > > >> On Sep 27, 2019, at 09:07, Björn Pettersson A via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Obviously we do not store into two locations (it is still a single >> two byte store). >> So is it (always) correct to interpret the list of

On Feb 1, 2011, at 1:34 PM, Andrew Trick wrote: > On Feb 1, 2011, at 1:08 PM, Andrew Clinton wrote: > >> I have a (non-entry) basic block that contains only PHI nodes and an >> unconditional branch (that does not branch to itself). Is it always >> possible to merge this block with it's successor and produce a >> semantically equivalent program? I'm