[LLVMdev] selection dag speedups / llc speedups

[Nick Lewycky]

Jan Voung wrote:
> Here are some recent stats of the fast vs local vs linear scan at O0 on
> "opt -std-compile-opts" processed bitcode files. The fast regalloc is
> still certainly faster at codegen than local with such bitcode files.
>   Let me know if the link doesn't work:
>
> https://spreadsheets.google.com/a/google.com/ccc?key=0At5EJFcCBf-wdDgtd2FoZjU4bFBzcFBtT25rQkgzMEE&hl=en
> <https://spreadsheets.google.com/a/google.com/ccc?key=0At5EJFcCBf-wdDgtd2FoZjU4bFBzcFBtT25rQkgzMEE&hl=en>

Hi Jan,

See the "/a/google.com/" part of the URL? Yeah, people without 
google.com logins can't read that.

There's no way to use docs to produce a document with your work account 
that is readable to the outside world, I've complained about it before. 
Export it instead.

Nick

> Misc stuff: I ran into an "UNREACHABLE executed" using linear scan on
> revision 104021, so I used an older version for that.
>
> 0  llc.hg          0x0000000000af4d7f
> 1  llc.hg          0x0000000000af54fa
> 2  libpthread.so.0 0x00007fb1734b67d0
> 3  libc.so.6       0x00007fb1725d2095 gsignal + 53
> 4  libc.so.6       0x00007fb1725d3af0 abort + 272
> 5  llc.hg          0x0000000000ad4932
> llvm::llvm_unreachable_internal(char const*, char const*, unsigned int)
> + 370
> 6  llc.hg          0x0000000000886426
> llvm::LiveIntervals::handleVirtualRegisterDef(llvm::MachineBasicBlock*,
> llvm::ilist_iterator<llvm::MachineInstr>, llvm::SlotIndex,
> llvm::MachineOperand&, unsigned int, llvm::LiveInterval&) + 3910
> 7  llc.hg          0x0000000000888429
> llvm::LiveIntervals::handleRegisterDef(llvm::MachineBasicBlock*,
> llvm::ilist_iterator<llvm::MachineInstr>, llvm::SlotIndex,
> llvm::MachineOperand&, unsigned int) + 409
> 8  llc.hg          0x000000000088ade0
> llvm::LiveIntervals::computeIntervals() + 2496
> 9  llc.hg          0x000000000088b56f
> llvm::LiveIntervals::runOnMachineFunction(llvm::MachineFunction&) + 447
> 10 llc.hg          0x00000000007b3493
> llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 115
> 11 llc.hg          0x0000000000a79ec0
> llvm::FPPassManager::runOnFunction(llvm::Function&) + 688
> 12 llc.hg          0x0000000000a79f13
> llvm::FPPassManager::runOnModule(llvm::Module&) + 67
> 13 llc.hg          0x0000000000a79a63
> llvm::MPPassManager::runOnModule(llvm::Module&) + 515
> 14 llc.hg          0x0000000000a79b42
> llvm::PassManagerImpl::run(llvm::Module&) + 114
> 15 llc.hg          0x0000000000a79bdd
> llvm::PassManager::run(llvm::Module&) + 13
> 16 llc.hg          0x00000000004d3112 main + 2802
> 17 libc.so.6       0x00007fb1725be1c4 __libc_start_main + 244
> 18 llc.hg          0x00000000004d0b09
>
>
> Stack dump:
> 0.      Program arguments: llc.hg -asm-verbose=false -O0
> 32/403.gcc/403.gcc.linked.bc -o
> 32/403.gcc/output/403.gcc.linked.bc.llc_O0.s
> 1.      Running pass 'Function Pass Manager' on module
> '32/403.gcc/403.gcc.linked.bc'.
> 2.      Running pass 'Live Interval Analysis' on function
> '@nonlocal_mentioned_p'
>
> - Jan
>
> On Mon, May 17, 2010 at 9:33 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk
> <mailto:stoklund at 2pi.dk>> wrote:
>
>
>     On May 17, 2010, at 9:09 PM, Rafael Espindola wrote:
>
>      >> The fast and local register allocators are meant to be used on
>     unoptimized code, a 'Debug build'. While they do work on optimized
>     code, they do not give good results. Their primary goal is compile
>     time, not code quality.
>      >
>      > Yes, we have a somewhat uncommon use case. It is fine to spend time
>      > optimizing bitcode (LTO is a OK), but we want to make the final IL ->
>      > Executable translation as fast as possible.
>
>     Do you know how the fast allocator performs in these conditions?
>     Have you compared it to the local allocator? I really focused my
>     efforts on unoptimized code.
>
>     /jakob
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev