Re: combine_givs_p address cost

[Michael Hayes <m dot hayes at elec dot canterbury dot ac dot nz>]

Richard Henderson writes:
 > The problem with that test is that it decides, with no surrounding
 > context, whether the giv should be combined.  Now suppose there are
 > twenty givs that could be combined instead of two.  Failing to allow
 > their combination means we'll have oodles of spills and oodles of
 > increments where offsets from one register would have sufficed.

Hang on, I'm confused ;-(  What I'm seeing is the opposite.
With combine_givs_p as it stands at present, too many address
registers are required rather than a few with offsets from them.

 > If you have specific suggestions for heuristics, I'm quite willing
 > to discuss them.  And we can always try them out on various problem
 > sets to see how they do.

I suppose the simplest heuristic would be a function of the number of
GIVs found in a loop and the number of address registers on the target
machine.  This could be supplemented by the ADDRESS_COST information
or whether all the displacements from a register could be converted
to autoincrements  (I'm about to submit patches to flow.c that
will convert a series of memory references into autoincrements).

Michael.