similar to: Compile time from IR

On Jun 14, 2011, at 1:07 AM, Duncan Sands wrote: > 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

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-folder -block-placement) targeting

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

Hi Jacob, At this point, I suspect there is a problem with maintaining liveness information during branch folding. Here is what I see: I have a basic block ready for branch optimization, that computes a predicate p10 on which a conditional branch depends. Notice that this is in the stage with physical registers. BB#2: derived from LLVM BB %while.cond.preheader Live Ins: %R3 %R5

The unchecked assertion that the same register is not added multiple times to the MBB::LiveIn list isn't being respected. Could we add an assertion to check for it? ==== //dwarc/Tools/MetaWare/Toolset/main/dev/llvm/include/llvm/CodeGen/MachineBasicBlock.h#6 - /remote/arctools/marksl/marksl_1/llvm/include/llvm/CodeGen/MachineBasicBlock.h ==== 295,298d294 < /// addLiveIn - Add the

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:

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} */'

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

On Tue, 19 Feb 2008, Bill Wendling wrote: > On my PPC G4 box, I'm getting this failure for TOT with llvm-gcc 4.2: Fixed. -Chris > 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

I would like to maintain the livein information for physical registers on basic blocks past register allocation, or recreate it if possible. The goal is to be able to run a late pass of DeadMachineInstrElim, which requires valid livein information. The X86 target returns false for requiresRegisterScavenging so passes like BranchFolding don't update the livein information. At that point I

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

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

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>

Hi, I upgraded the Visual Studio SLN file to work with 2005 and had to make some changes. The first two have to do with the fact that the debug implementation of 2005's STL does all sort of validation, that's why they didn’t show up on 2003. I'm not set up for patch submission yet, but if somebody has time to review these changes that'd be greatly appreciated. Meanwhile

Hola Jaap, I'm curious which version of the source are you working with? It sounds like you and I were working on the same problem yesterday, but I didn't see those particular compiler errors. (I saw a couple of other ones for which I submitted a patch). I did see errors like the ones you saw with the CVS LLVM 2.0 sources a while back, namely the missing < operator and the debug STL

But, the branch folding pass, or whatever passes are supposed to reorder the blocks based on the CFG, are not doing so in this case. Otherwise there is no way that blocks 2 and 4 should be printing out before blocks 3 & 5. Renumber blocks just seems to reorder the values based on their pre-set block number, but when the CFG is modified these number should modified also to follow the new