similar to: [CodeGen] CodeSize - TailMerging and BlockPlacement

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

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

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

Eli Friedman <eli.friedman at gmail.com> writes: >> Ah. So is the MachineFunction version expected to work correctly? > > It's part of the default set of CodeGen passes. It is? Was that true in 3.1? I can't see where it is initialized in llc. I probably missed something important. :) Thanks! -David

On Jun 13, 2011, at 12:29 AM, John McCall wrote: > > On Jun 12, 2011, at 11:24 PM, Bill Wendling wrote: > >> On Jun 12, 2011, at 4:40 PM, John McCall wrote: >> >>> On Jun 12, 2011, at 2:14 PM, Cameron Zwarich wrote: >>> >>>> On Jun 12, 2011, at 1:25 AM, Duncan Sands wrote: >>>> >>>>> Hi Sohail, >>>>>

As stated in an earlier email, I am working on getting break/continue to work correctly for my backend, but I ran into another issue with codegen and the CFG. It seems that code gen is not done based on the CFG, but rather on the block numbers, and the function call MachineFunction::RenumberBlocks doesn't renumber the blocks based on the CFG. So how can I modify the CFG so that when codegen

The comment in test/CodeGen/X86/branchfolding-undef.mir states that such merging is legal, however doing so can actually generate wrong code: Consider this (valid code): --- name: fred tracksRegLiveness: true body: | bb.0: successors: %bb.1, %bb.2 J2_jumpt undef %p0, %bb.2, implicit-def %pc J2_jump %bb.1, implicit-def %pc bb.1: successors: %bb.3 %r0 =

On Oct 13, 2008, at 5:14 PMPDT, Villmow, Micah wrote: > As stated in an earlier email, I am working on getting break/ > continue to work correctly for my backend, but I ran into another > issue with codegen and the CFG. It seems that code gen is not done > based on the CFG, but rather on the block numbers, and the function > call MachineFunction::RenumberBlocks doesn’t

Hi, I am working on a custom backend, and I am trying to figure out how to deal with some branching inefficiencies in my output code, and the best way to fix it. So, let's say I am compiling a small function that takes the sum of an array. int loop(int* array, int n) { int ret = 0; for (int i = 0; i < n; i++) { ret += array[i]; } return ret; } The problem I am having is that

Hi Eric, all, Currently, there isn't a good way to force enable/disable GlobalMerge. Targets decide whether to create the pass based on the optimization level (which is how it should be). The problem is when you want to override that decision. We have -enable-global-merge, true by default, which should really be -disable-global-merge, as it only works as a last-resort way to force-disable

MachineBasicBlock allows for multiple terminators. Unconditional branches and returns are marked as terminators; the MIPS backend also marks conditional branches as terminators. The MachineBasicBlock then has a helper function getFirstTerminator which iterates from the first terminator to the end of the MBB. So it seems to me that an MBB is a kind of superblock, single entrance and multiple side

Hi again, On my PPC G4 box, I'm getting this failure for TOT with llvm-gcc 4.2: Running /Users/wendling/llvm/llvm.src/test/CodeGen/X86/dg.exp ... FAIL: /Users/wendling/llvm/llvm.src/test/CodeGen/X86/2008-02-18- TailMergingBug.ll for PR1909 Failed with exit(1) at line 1 while running: llvm-as < /Users/wendling/llvm/llvm.src/test/CodeGen/ X86/2008-02-18-TailMergingBug.ll | llc -march=x86

http://llvm.org/viewvc/llvm-project/llvm/tags/RELEASE_31/final/lib/CodeGen/Passes.cpp?revision=156747&view=markup void TargetPassConfig::addMachineSSAOptimization() { // Pre-ra tail duplication. if (addPass(EarlyTailDuplicateID) != &NoPassID) printAndVerify("After Pre-RegAlloc TailDuplicate"); /// Add passes that optimize machine instructions after register allocation.

Hi Tim, There are three remaining broken tests on AArch64 on Gabor's buildbot: http://lab.llvm.org:8011/builders/llvm-aarch64-linux CodeGen/Generic/2011-07-07-ScheduleDAGCrash.ll ** LLVM ERROR: Can't handle live physical register dependency! CodeGen/Generic/asm-large-immediate.ll ** error: invalid operand in inline asm: '/* result: ${0:c} */'

Yes, immediately after branch folding the code would still behave the same as the original. At the same time, any subsequent optimization may "exploit" the incorrect liveness information to do something bad. If you add -run-pass if-converter, you'll get: # After If Converter # Machine code for function fred: IsSSA, NoPHIs, TracksLiveness, NoVRegs BB#0: %R0<def>

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 block is empty, make everyone use its fall-through, not

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 Sat, Mar 28, 2020 at 2:20 PM Eli Friedman <efriedma at quicinc.com> wrote: > This would specifically be for cases where we try to rewrite the > signature? I would assume we should forbid rewriting the signature of a > call with an operand bundle. And once some optimization drops the bundle > and preallocated marking, to allow such rewriting, the signature doesn’t > need

On Jul 23, 2009, at 12:10 PM, robert muth wrote: > Bob: > > Thanks for cleaning this up. I like the new patch much better than > the old one. > Teaching the (abstract) ConstantValue class about jumptable indices > is a little > bit ugly but I do not see any better solution without massive > refactoring. > I have added TODOs here and elsewhere and plan to address

Hi All, I've encountered an issue where tail merging MIs is causing a problem with the post-RA MI scheduler dependency analysis and I'm not sure of the best way to address the problem. In my case, the branch folding pass (lib/CodeGen/BranchFolding.cpp) is merging common code from BB#14 and BB#15 into BB#16. It's clear that there are 4 common instructions (marked with an *) in BB#14