search for: branchfold

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

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; > > The erase clears the _Mycont field (i.e. the iterator’s contain...

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

Hi! Does anyone know how it should be interpreted when one MI has multiple MachineMemOperands? (I've tried to find information but could not find any clear definition.) For example BranchFolder may do things like this (also see https://godbolt.org/z/iphFH4): # *** IR Dump Before Control Flow Optimizer ***: bb.0.entry: ... JCC_1 %bb.2, 5, implicit killed $eflags JMP_1 %bb.1 bb.1.s1: CALL64pcrel32 @bar, ... , implicit-def $rax MOV16mr killed renamable $rax, 1, $noreg, 0, $noreg...

...Trace()+0x17)[0xc2f98f] llc((anonymous namespace)::SignalHandler(int)+0x10e)[0xc2fbfc] /lib/libc.so.6[0x2b59c5fb5110] /lib/libc.so.6(gsignal+0x3b)[0x2b59c5fb507b] /lib/libc.so.6(abort+0x10e)[0x2b59c5fb684e] /lib/libc.so.6(__assert_fail+0x104)[0x2b59c5faeaf4] llc[0x7d8149] llc((anonymous namespace)::BranchFolder::ReplaceTailWithBranchTo(llvm::ilist_iterator<llvm::MachineInstr>, llvm::MachineBasicBlock*)+0xe3)[0xab7ef9] llc((anonymous namespace)::BranchFolder::TailMergeBlocks(llvm::MachineFunction&)+0x451)[0xab837b] llc((anonymous namespace)::BranchFolder::runOnMachineFunction(llvm::MachineFunct...

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: >> >> MergePotentials.erase(CurMPIter); >> if (CurMPIter==B) >> break; >> >> The erase clears the _Mycont fi...

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

...s anyone written a pass at the MachineFunction level which combines >> machine basic blocks which is guaranteed to be the single predecessor >> to another block? Or is there a reason not to combine them? > > I'm not sure exactly what transformation you're referring to, but BranchFolder::OptimizeBranches does a lot of things like that.

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

...llvm::MachineBasicBlock::erase (this=0x931b3ac, I=..., E=...) at /work/llvm/trunk/llvm/include/llvm/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::OptimizeFun...

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

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

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

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

...::MergeBlockIntoPredecessor, then the predecessor phis should have no uses other than successor phis. That would violate strict SSA (the CFG edge you described is a dominance frontier). I forgot to ask why you're doing this. If the goal is to remove a branch, that would typically be handled by BranchFolder during codegen after phis have been removed. I don't see a problem forcing the CFG to be more canonical earlier, but if the successor is in a deeper loop, then you could be eliminating a preheader and forcing compensation code into the loop. In fact, I wouldn't be surprised if some loop p...