Displaying 3 results from an estimated 3 matches for "handlevirtualregisterdef".
2010 May 18
3
[LLVMdev] selection dag speedups / llc speedups
...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::Ma...
2010 May 18
0
[LLVMdev] selection dag speedups / llc speedups
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
2010 May 18
2
[LLVMdev] selection dag speedups / llc speedups
> 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