search for: machineblockplac

I'm trying to port llvm-lua so it's buildable with llvm trunk. A problem I'm running into is that it uses the older BlockPlacement pass. From searching around and reading llvm's commit, this pass has been replaced and superseded by Chandler's MachineBlockPlacement pass. What's unclear to me is how exactly do you add this pass to say a function pass manager? The current llvm-lua code has something like this: // ... if(OptLevel > 1) { TheFPM = new llvm::FunctionPassManager(M); // add some passes for opt1 // ... if(Opt...

...r3,r3 > > 2. Which pass is responsible for cleaning up unconditional jumps that > should be fall-throughs: > 0x0000000010005d88 <+1688>: b 0x10005d8c <._Z11sfoo+1692> > 0x0000000010005d8c <+1692>: ld r3,-32056(r2) > This should be handled by the MachineBlockPlacement (among others). Do you have a reduced est case? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120607/1e4f2d11/attachment.html>

I am working on cleaning up some PPC code generation. Two questions: 1. Which pass is responsible for cleaning up self-moves: 0x00000000100057c0 <+208>: mr r3,r3 2. Which pass is responsible for cleaning up unconditional jumps that should be fall-throughs: 0x0000000010005d88 <+1688>: b 0x10005d8c <._Z11sfoo+1692> 0x0000000010005d8c <+1692>: ld

...n architecture whose jump via table instruction includes the range check. If the index is out of range, the jump table instruction just falls through. I implemented a pass to remove the range check generated before the jump table instruction because it is superfluous. This causes as assertion in MachineBlockPlacement.cpp: assert((!TII->analyzeBranch(*PrevBB, TBB, FBB, Cond) || !PrevBB->canFallThrough()) && "Unexpected block with un-analyzable fallthrough!"); The method MachineBasicBlock::getFallThrough() uses TII->analyzeBranch(). Using analyz...

...mproved into something that is on-by-default eventually, but I'll be the first to say it's almost certainly not ready for that just yet. I would like to see this go in ASAP under a flag. I prefer to see development as commits rather than a series of updated patches. Could you rename it to MachineBlockPlacement.cpp first, though? That makes it clear it's a CodeGen pass, and the BlockPlacement2 name is icky. > I'm more hopeful that we can delete the existing block placement pass, and direct anyone interested in profile file guided stuff to write a simple pass to load profiles into metadata...

I'm getting some odd behavior out of MBP and was hoping someone knowledge of the code might be able to give some guidance. Fair warning, I'm trying to describe a problem in code I don't really understand, so if something doesn't make sense, assume I misunderstood something. The problematic case I'm seeing is that cold blocks are being placed between the preheader and

...Aborted. 0x00007ffff785c945 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff785c945 in raise () from /lib64/libc.so.6 #1 0x00007ffff785df21 in abort () from /lib64/libc.so.6 #2 0x00007ffff7855810 in __assert_fail () from /lib64/libc.so.6 #3 0x00007ffff62b283d in (anonymous namespace)::MachineBlockPlacement::runOnMachineFunction(llvm::MachineFunction&) () from /opt/kernelgen/lib/libLLVM-3.2svn.so #4 0x00007ffff64cfb9f in llvm::FPPassManager::runOnFunction(llvm::Function&) () from /opt/kernelgen/lib/libLLVM-3.2svn.so #5 0x00007ffff64cfc43 in llvm::FPPassManager::runOnModule(llvm::Module&...

Hi, I would like to learn the details regarding what exactly PGO does for basic block layout/code placement optimizations in llvm. Could you please point me to some descriptions? Is it close to this paper (Karl Pettis and Robert C. Hansen. 1990. Profile guided code positioning. PLDI'90) http://perso.ensta-paristech.fr/~bmonsuez/Cours/B6-4/Articles/papers15.pdf? Whether it is purely

...Perf profile again. 2.4 Example of pass pipeline Here is the one sample pass pipeline for AFDO + ThinLTO compilation. // Pass Pipeline: InsertBaseDiscrimator SampleProfileLoader in FE ... CM inline ... SampleProfileLoader in BE ... AddFSDiscriminator(kind_mbp) FSProfileLoader(kind_mbp) MachineBlockPlacement AddFSDiscriminator(kind_branchfolding) FSProfileLoader(kind_branchfolding) BranchFoldingPass … AddFSDiscriminator(kind_final) In the above pass pipeline. MachineBlockPlacement and BranchFoldingPass are the two target optimization passes. MachineBlockPlacement can obviously be benefited f...

...-print-after-all and/or -debug might well shed some light on what's happening. Other possible bugs are in implementations of AnalyzeBranch, InsertBranch or RemoveBranch. They're target callbacks LLVM uses to do its more invasive block movement. The place to start debugging is lib/CodeGen/MachineBlockPlacement.cpp. Something in there is probably getting confused. Cheers. Tim.

...MPM.add(createCFGSimplificationPass()); > > but, other things do run afterward. Maybe we need another one of these > closer to the end? > > One other thing to realize is that an empty block like this might not > actually turn up in any generated machine code because of how > MachineBlockPlacement (and other MI-level passes) work. > > -Hal > > ----- Original Message ----- > > From: "Russell Wallace via llvm-dev" <llvm-dev at lists.llvm.org> > > To: "llvm-dev" <llvm-dev at lists.llvm.org> > > Sent: Sunday, September 20, 2015...

Hi, guys, I compiled a subroutine with -O2, and llvm backend produced codes like: ################################################################## LBB0_32: ... R31 = -1 R20 = R31 * R20; .... bnz R2, LBB0_34 LBB0_31: ... b LBB0_34 LBB0_33: # weird basic block? R20 = R5 LBB0_34: ....

...isabled in WebAssemblyTargetMachine is MachineCopyPropagation. > Several passes (post-RA MachineLICM, StackSlotColoring) already only run if RA runs. > Everything else is running today. Currently that's ShrinkWrap, BranchFolder, ExpandPostRAPseudos, PostRAScheduler, GCMachineCodeAnalysis, MachineBlockPlacement, FuncletLayout, and StackMapLiveness. All of these run after our register coloring pass. I don’t know for the other passes, but I don’t think it makes sense to teach PrologEpilogInserter to work on virtual registers, since part of its job is to get rid of any virtual registers created when lo...

...tRAMachineLICM ShrinkWrap PrologEpilogInserter Machine late optimization: BranchFolderPass TailDuplicate MachineCopyPropagation PostRAScheduler ExpandPostRAPseudos ImplicitNullChecks (optional) PostMachineScheduler or PostRAScheduler GC: GCMachineCodeAnalysis GC info printer Block Placement: MachineBlockPlacement MachineBlockPlacementStats FuncletLayout StackMapLiveness LiveDebugValues All of the pre-regalloc passes (and analyses) would just get marked as supporting virtual registers. Here are some notes about passes of interest: PostRAMachineLICM (if not overriden by the target) is just the same...

...rf profile again. 2.4 Example of pass pipeline Here is the one sample pass pipeline for AFDO + ThinLTO compilation. // Pass Pipeline: InsertBaseDiscrimator SampleProfileLoader in FE ... CM inline ... SampleProfileLoader in BE ... AddFSDiscriminator(kind_mbp) FSProfileLoader(kind_mbp) MachineBlockPlacement AddFSDiscriminator(kind_branchfolding) FSProfileLoader(kind_branchfolding) BranchFoldingPass … AddFSDiscriminator(kind_final) In the above pass pipeline. MachineBlockPlacement and BranchFoldingPass are the two target optimization passes. MachineBlockPlacement can obviously be benefited...

...2. Which pass is responsible for cleaning up unconditional jumps that > should be fall-throughs: > 0x0000000010005d88 <+1688>: b 0x10005d8c <._Z11sfoo+1692> > 0x0000000010005d8c <+1692>: ld r3,-32056(r2) > > > This should be handled by the MachineBlockPlacement (among others). Do > you have a reduced est case? > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part ---...

...n raise () from /lib64/libc.so.6 > (gdb) bt > #0 0x00007ffff785c945 in raise () from /lib64/libc.so.6 > #1 0x00007ffff785df21 in abort () from /lib64/libc.so.6 > #2 0x00007ffff7855810 in __assert_fail () from /lib64/libc.so.6 > #3 0x00007ffff62b283d in (anonymous > namespace)::MachineBlockPlacement::runOnMachineFunction(llvm::MachineFunction&) > () from /opt/kernelgen/lib/libLLVM-3.2svn.so > #4 0x00007ffff64cfb9f in > llvm::FPPassManager::runOnFunction(llvm::Function&) () from > /opt/kernelgen/lib/libLLVM-3.2svn.so > #5 0x00007ffff64cfc43 in > llvm::FPPassMana...

...ass()); > > > > but, other things do run afterward. Maybe we need another one of > > these closer to the end? > > > > One other thing to realize is that an empty block like this might not > > actually turn up in any generated machine code because of how > > MachineBlockPlacement (and other MI-level passes) work. > > > > -Hal > > > > > > > > ----- Original Message ----- > > > From: "Russell Wallace via llvm-dev" < llvm-dev at lists.llvm.org > > > > To: "llvm-dev" < llvm-dev at lists.llvm...

...t the feasibility this approach? As to step 1, I haven't dug too deeply into the problem yet, but I'm starting from the assumption that we'll be moving only the modules that start with 'Machine' into the new library. These are: - MachineBasicBlock - MachineBlockFrequencyInfo - MachineBlockPlacement - MachineBranchProbabilityInfo - MachineCodeEmitter - MachineCopyPropagation - MachineCSE - MachineDominators - MachineFunctionAnalysis - MachineFunction - MachineFunctionPass - MachineFunctionPrinterPass - MachineInstrBundle - MachineInstr - MachineLICM - MachineLoopInfo - MachineModuleInfo -...

Hello, I'm trying to minimize the processing time for llc -O3 by using a three step compilation process of 1. llc input.bc -stopafter=targetlibinfo -o input.mir 2. llc -run-pass={....min passes...} input.mir -o opt.mir 3. llc -startafter=machine-opt-remark-emitter -filetype=obj opt.mir -o final.obj Examining the passes produced by llc for O1,O2,O3 I compared (with XXX = {1,2,3}): llc