[RFC, ivopts] fix bugs in ivopts address cost computation
Hans-Peter Nilsson
hp@bitrange.com
Sat Jun 9 02:58:00 GMT 2012
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
More information about the Gcc-patches
mailing list