Displaying 2 results from an estimated 2 matches for "l14_tmp_2e_4".
Did you mean:
l14_tmp_2e_5
2004 May 09
0
[LLVMdev] Testing LLVM on OS X
...o emit syntactic loops around the real
loops, and it seems to make a big difference. LLVM now generates this
code (note that the actual loop is not actually responsible for control
flow, it's unreachable):
void test(int l7_X) {
unsigned l8_indvar;
unsigned l8_indvar__PHI_TEMPORARY;
int *l14_tmp_2E_4;
int l7_tmp_2E_7;
unsigned l8_indvar_2E_next;
l8_indvar__PHI_TEMPORARY = 0u; /* for PHI node */
goto l13_no_exit;
do { /* Syntactic loop 'no_exit' to make GCC happy */
l13_no_exit:
l8_indvar = l8_indvar__PHI_TEMPORARY;
l14_tmp_2E_4 = &Array[l8_indvar];
l7_tmp_2E_...
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