search for: l8_tmp_2e_180

Displaying 3 results from an estimated 3 matches for "l8_tmp_2e_180".

Did you mean: l2_tmp_2e_182
2004 May 17
2
[LLVMdev] Testing LLVM on OS X
...zip's longest_match function, part of the code generated by CBE looks like this: l13_shortcirc_next_2E_11: l8_chain_length_2E_039 = (((l2_tmp_2E_182) ? (4294967295u) : (0u))) + l8_chain_length_2E_1; .. some other code ... l13_loopcont_2E_0: ... some other code ... l2_tmp_2E_182 = l8_tmp_2E_180 > l8_mem_tmp_2E_0; if (l2_tmp_2E_182) { goto l13_shortcirc_next_2E_11; } else { goto l13_UnifiedReturnBlock; } Basically it does that check and puts the result in l2_tmp_2E_182, then uses that in the if check and the ternary thing. When this is compiled, the assembly that...
2004 May 09
0
[LLVMdev] Testing LLVM on OS X
On Tue, 4 May 2004, Chris Lattner wrote: > On Tue, 4 May 2004, Chris Lattner wrote: > > I suspect that a large reason that LLVM does worst than a native C > > compiler with the CBE+GCC is that LLVM generates very low-level C code, > > and I'm not convinced that GCC is doing a very good job (ie, without > > syntactic loops). > > Yup, this is EXACTLY what is
2004 May 04
6
[LLVMdev] Testing LLVM on OS X
On Tue, 4 May 2004, Chris Lattner wrote: > I suspect that a large reason that LLVM does worst than a native C > compiler with the CBE+GCC is that LLVM generates very low-level C code, > and I'm not convinced that GCC is doing a very good job (ie, without > syntactic loops). Yup, this is EXACTLY what is going on. I took this very simple C function: int Array[1000]; void test(int