Re: EGCS bad on loop invariant optimization ?

[Gabriel Dos Reis <Gabriel.Dos-Reis@dptmaths.ens-cachan.fr>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1955 bytes --]

>>>>> «Martin», Martin von Loewis <martin@mira.isdn.cs.tu-berlin.de> wrote:

[code snipped]

>> Can't EGCS see that a.data, b.data, c.data are loop invariants and
>> then move the loads out of the loop ? At least, one can expect
>> b.data and c.data to be subject of this kind of optimization since the
>> only way to access them is through the (leaf) *const* class member
>> fonction `array::operator[](size_t) const'. What am I missing ? 

Martin> I believe this would depend on how ::operator new is implemented.  It
Martin> *could* return pointers into the stack, so that the writes to a[i]
Martin> overwrite the contents of b and c, so that reloading b.date and c.data
Martin> is necessary.

Martin> Of course, ::operator new never does such things. g++ doesn't now
Martin> that, though, and assumes worst-case.

Hmm. I can't get the point. Let me show my ignorance. Consider the
following code:

inline double& nth_element(double* data, unsigned i)
{ return data[i]; }

inline double nth_element(const double* data, unsigned i)
{ return data[i]; }


int main()
{
    const unsigned n = 1000;
    double* a = new double[n];
    double* b = new double[n];
    double* c = new double[n];

    for (unsigned i=0; i<n; ++i)
        nth_element(a, i) = nth_element(static_cast<const double*>(b), i)
            + nth_element(static_cast<const double*>(c), i);

    return 0;
}
    

EGCS-980325 with -O option outputs:

main:
.LLFB1:
	!#PROLOGUE# 0
	save %sp,-112,%sp
.LLCFI0:
	!#PROLOGUE# 1
	sethi %hi(8000),%l0
	call __builtin_vec_new,0
	or %l0,%lo(8000),%o0
	mov %o0,%l1
	call __builtin_vec_new,0
	or %l0,%lo(8000),%o0
	mov %o0,%i0
	call __builtin_vec_new,0
	or %l0,%lo(8000),%o0
	mov %o0,%o2
	mov 0,%o1
.LL9:
	sll %o1,3,%o0
	ldd [%i0+%o0],%f2
	ldd [%o2+%o0],%f4
	faddd %f2,%f4,%f2
	add %o1,1,%o1
	cmp %o1,999
	bleu .LL9
	std %f2,[%l1+%o0]
	ret
	restore %g0,0,%o0


As you can see, there is no store/load of a, b and c inside the loop. 

-- Gaby