Hi, > > (7) If the computed address cost turns out to be 0, the current code > > (for some unknown reason) is turning that into 1, which can screw up > > the relative costs of address computations vs other operations like > > addition. > > > > I've come up with the attached patch to try to fix these things. The > > biggest change is that I have discarded the code for precomputing and > > caching costs and instead go straight to querying the target back end > > for the cost for the specific address computation we're handed; this > > makes the code a lot simpler. I would kind of like to get rid of > > multiplier_allowed_in_address_p too, but it's being used in a couple > > places other than the address computation and it seemed better not to > > mess with that for now. The other fixes are pretty straightforward. > > Can you split the patch into pieces fixing the above bugs separately? > Removing the pre-compute and caching is the most questionable change, > the others look like real bugs (the symbol cost might be questionable as > well).
the changes seem reasonable to me (with the caveat about caching). On the other hand, an important thing to keep in mind is that all these are just heuristics that cannot model the actual costs very realistically. Furthermore, due to interference from further optimizations, there is no guarantee that say the choices of the addressing modes by ivopts will actually be respected. Consequently, improving the cost computation will not necessarily improve the resulting code quality, and beyond some point, any such improvements become essentially irrelevant. So, any changes complicating the model should be backed by benchmarking, as otherwise there is no way to say whether there are actually benefitial or not, Zdenek
