Re: BCT optimization

[David Edelsohn <dje at watson dot ibm dot com>]

>>>>> Jeffrey A Law writes:

Jeff> I think I was either planning on making those variables global or
Jeff> having a function to get them.  I think BCT belongs in loop.c since
Jeff> it has nothing to do with loop unrolling.

Jeff> One could argue that some of the code in unroll.c should move into
Jeff> loop.c, and that may be a good thing to do.

	That's fine as well.  The split of functionality between loop.c
and unroll.c does not make a lot of sense in some cases.  The information
needs to be shared one way or another. 

Jeff> Yeah, I'd noticed this myself.  I don't remember if I'd started down
Jeff> the path to delay committing to BCT until insert_bct or not.

	analyze_loop_iterataions() mainly exists to determine some
characteristics of the loop before later transformations mask it.  That is
exactly what loop_iterations() does as well and it also stuffs its
information away in the (currently) static variables much the same way
that analyze_loop_iterations() creates its vectors of loop information.
If insert_bct() uses the information acquired by loop_iterations(), there
does not seem to be any reason for analyze_loop_iterations() to exist.

	The only additional tests made by analyze_loop_iterations() are
checking for jump tables, calls, and indirect branches in the loop.  Those
tests are equally valid to be performed in insert_bct().  No
transformation should mask that information; if some transformation
removes any of that, so much the better.

	I cannot see why the BCT optimization needs vectors of loop
information for anything other than COUNT_REGISTER in use.  I think the
authors were confused about the multiple places that unroll() is called
requiring unroll_factor[] to be a vector.

	I don't really understand loop preconditioning well enough to
tackle that problem just now.

David