similar to: [LLVMdev] ScheduleDAGInstrs computes deps using IR Values that may be invalid

Displaying 5 results from an estimated 5 matches similar to: "[LLVMdev] ScheduleDAGInstrs computes deps using IR Values that may be invalid"

2018 Dec 05
2
Strange regalloc behaviour: one more available register causes much worse allocation
Preamble -------- While working on an IR-level optimisation completely unrelated to register allocation I happened to trigger some really strange register allocator behaviour causing a large regression in bzip2 in spec2006. I've been trying to fix that regression before getting the optimisation patch committed, because I don't want to regress spec2006, but I'm basically fumbling in
2018 Dec 05
3
Strange regalloc behaviour: one more available register causes much worse allocation
enableAdvancedRASplitCost() does the same thing as ConsiderLocalIntervalCost, but as a subtarget option instead of a command-line option, and as I’ve said it doesn’t help because it’s a non-local interval causing the eviction chain (RAGreedy::splitCanCauseEvictionChain only considers the local interval for a single block, and it’s unclear to me how to make it handle a non-local interval). John
2010 Dec 17
3
Alternative to extended recode sintax?
Dear R-users, I have a factor variable within my data frame which I derive week after week from a POSIXct variable using the cut(var,"weeks") command I have found in the chron package. The levels() command gives me: [1] "2009-03-30 00:00:00" "2009-04-06 00:00:00" "2009-04-13 00:00:00" "2009-04-20 00:00:00" "2009-04-27 00:00:00"
2015 May 06
2
[LLVMdev] [lld] Wrong references for C++ COMDAT groups
Hi, Checking the llvm test-suite SingleSource/Regression/C++/EH/class_hierarchy testcase on aarch64 I noted something strange: Dump of assembler code for function _Z4funcj: 0x0000000000400650 <+0>: stp x22, x21, [sp,#-48]! 0x0000000000400654 <+4>: stp x20, x19, [sp,#16] 0x0000000000400658 <+8>: stp x29, x30, [sp,#32] 0x000000000040065c
2015 May 07
2
[LLVMdev] [lld] Wrong references for C++ COMDAT groups
Looks like it is also not working on x86_64, using clang/lld I am seeing a segmentation fault: Dump of assembler code for function _Z4funcj: 0x0000000000400590 <+0>: push %rbp 0x0000000000400591 <+1>: push %rbx 0x0000000000400592 <+2>: push %rax 0x0000000000400593 <+3>: mov %edi,%ebp 0x0000000000400595 <+5>: pop %rdx 0x0000000000400596