Re: [RFC, ivopts] fix bugs in ivopts address cost computation

[Hans-Peter Nilsson <hp at bitrange dot com>]

On Tue, 5 Jun 2012, Sandra Loosemore wrote:

> (1) While the address cost computation is assuming in some situations
> that pre/post increment/decrement addressing will be used if
> supported by the target, it isn't actually using the target's address
> cost for such forms -- instead, just the cost of the form that would
> be used if autoinc weren't available/applicable.

There are lots of bugzilla entries complaining about bad
autoinc/dec generation.  Maybe your patch solves some of them?

> (2) The computation to determine which multiplier values are supported
> by target addressing modes is constructing an address rtx of the form
> (reg * ratio) to do the tests.  This isn't a valid address RTX on
> Hexagon, although both (reg + reg * ratio) and (sym + reg * ratio)
> are.

Yeah, I've spotted this one and (7), funny in a bad way.  It's
not a sane addressing mode except as a corner-case of (reg*ratio
+ constant) (e.g. constant=sym).  A value in a register, and
just multiply that by a constant to use as an address?  When
would that be useful?  Should a target include the corner-case
as a special-case addressing-mode just to appease ivopts?  Made
me think less of ivopts.  Dunno if I entered a PR, mea culpa
...doesn't seem so.

> I bootstrapped and regression-tested the patch on x86_64.  I haven't
> tried to benchmark the performance effect of the patch on anything
> other than Hexagon; there I found that, once ivopts actually started
> paying attention to the target address costs function, it needed to be
> re-tuned.  So, it wouldn't surprise me if other back ends could
> benefit from some tweaking as well, depending on the extent to which
> they're affected by the bugs I listed above.

Right, but the lesson learned is to just ignore effects on other
targets...  In all fairness, I don't think there's anything to
do regarding this patch in the default cost function, but it'd
nice with a heads-up before committing the final version of this
patch for a change though, maybe even with rtx cost
tweaking-examples from a target of your choice (in the tree) if
I could wish.

> Comments, complaints, proposals for alternate fixes, etc?  Or OK to
> commit?

Thank you!  Others mentioned benchmarking on some major target,
so I'll just add a wish for some PR annotations, any target with
ivopts-related PR's.

brgds, H-P