similar to: [LLVMdev] Bug in BranchFolding.cpp:OptimizeBlock

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

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:

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

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 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 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, I have a compiler project using an LLVM backend (compiled for 64 bit windows), and since it has started to get to production level source code sizes the compile times have gotten somewhat extreme (around 30 mins each time). Not sure what is the best metric for measuring whether 30 mins is reasonable. The .ll output file is ~1.5 million lines. A snip of the top of the stats output is

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

On Jan 4, 2014, at 4:38 AM, Haishan <hndxvon at 163.com> wrote: > At 2014-01-04 06:11:38,"Jakob Stoklund Olesen" <stoklund at 2pi.dk> wrote: > > On Jan 3, 2014, at 1:52 PM, Andrew Trick <atrick at apple.com> wrote: > >> He really just wants to rerun LiveIntervals analysis, but LiveVariables is no longer available. Would it work just to clear all

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

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

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