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
