similar to: [LLVMdev] 2008-02-18-TailMergingBug.ll Failure

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

Hi all, In the last few days, some change introduced an internal compiler error. On my G4 (PPC), I'm getting this: $ cat testcase.i struct A {}; struct B { struct A c[0]; }; extern const struct B *pB; void bork(void) { const struct A *pA = pB->c; } $ /Users/wendling/llvm/llvm-gcc-4.2.obj/./gcc/xgcc -B/Users/wendling/ llvm/llvm-gcc-4.2.obj/./gcc/ -B/Users/wendling/llvm/llvm-

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 25, 2008, at 9:35 PM, Bill Wendling wrote: > Sorry, I forgot to mention. It's a PPC PowerBook G4 running Mac OS X > 10.4.11. > > -bw OK, ppc32 EH used to work better than this (although I haven't tried it on 10.4). I'll have a look. > On Jan 25, 2008, at 6:14 PM, Dale Johannesen wrote: > >> What target? >> >> On Jan 25, 2008, at 6:06 PM,

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

Sorry, I forgot to mention. It's a PPC PowerBook G4 running Mac OS X 10.4.11. -bw On Jan 25, 2008, at 6:14 PM, Dale Johannesen wrote: > What target? > > On Jan 25, 2008, at 6:06 PM, Bill Wendling wrote: > >> Here are my test results for the 2.2 prerelease. >> >> Built objDir == srcDir, release, and with the pre-built LLVM-GCC >> binary. >>

Yes, this is me. I'll look at this tonight when I have access to a machine. Evan On Jan 27, 2008, at 1:01 AM, Bill Wendling <isanbard at gmail.com> wrote: > Hi all, > > In the last few days, some change introduced an internal compiler > error. On my G4 (PPC), I'm getting this: > > $ cat testcase.i > struct A {}; > struct B { > struct A c[0]; > };

On Jan 25, 2008, at 9:43 PM, Dale Johannesen wrote: > > On Jan 25, 2008, at 9:35 PM, Bill Wendling wrote: > >> Sorry, I forgot to mention. It's a PPC PowerBook G4 running Mac OS X >> 10.4.11. >> >> -bw > > OK, ppc32 EH used to work better than this (although I haven't tried > it on 10.4). I'll have a look. I should clarify, what is the

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

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

What target? On Jan 25, 2008, at 6:06 PM, Bill Wendling wrote: > Here are my test results for the 2.2 prerelease. > > Built objDir == srcDir, release, and with the pre-built LLVM-GCC > binary. > > "make test" results: > > === Summary === > > # of expected passes 2533 > # of expected failures 6 > > > -bw

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 =

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

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

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

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