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