similar to: How to create a column in dependence of another column

Displaying 5 results from an estimated 5 matches similar to: "How to create a column in dependence of another column"

2006 Aug 21
0
[LLVMdev] Recalculating live intervals
> I'm not sure about one thing: you assign stack slot to each new register you > replace the spilled one with. And then you need to allocate physical > registers to them. Is it possible to assign physical register to the virtual > one which has a stack slot already? > Yes. The stack slot is the place where the value will be stored in memory, but, when that value is effectively
2006 Aug 23
1
[LLVMdev] Recalculating live intervals
Fernando Magno Quintao Pereira wrote: >> I'm not sure about one thing: you assign stack slot to each new register you >> replace the spilled one with. And then you need to allocate physical >> registers to them. Is it possible to assign physical register to the virtual >> one which has a stack slot already? >> > > Yes. The stack slot is the place where the
2006 Aug 21
3
[LLVMdev] Recalculating live intervals
I'm not sure about one thing: you assign stack slot to each new register you replace the spilled one with. And then you need to allocate physical registers to them. Is it possible to assign physical register to the virtual one which has a stack slot already? On 8/21/06, Fernando Magno Quintao Pereira <fernando at cs.ucla.edu> wrote: > > > > So what addIntervalsToSpills
2012 May 23
0
[LLVMdev] Assembly macros instantiation problem
Hello, I've noticed a following strange behavior: clang-3.2 fails to compile/parse any assembly code that invokes macros which named arguments contains non alphanumeric characters. For example, compilation of the following code snippet would fail with "Parameter not found" error: .macro mov_macro reg_1, reg_2 movl %\reg_1, %\reg_2 .endm mov_macro eax, ebx Although, if one
2009 Jan 28
3
[LLVMdev] uses of unwind lead to crashes
I have what appears to be a bug in LLVM... I'm deeply hesitant to label it a bug, given my lack of experience with LLVM, but the behaviour of this fragment strongly suggests a bug. In particular, compiling and running this fragment using a fresh SVN build yields this stderr: uccello:/tmp clements$ lli a.out.bc 0 lli 0x005e72b6 char const* std::find<char const*,