On Tue, Aug 12, 2014 at 04:53:38PM +0100, pins...@gmail.com wrote: > > > > On Aug 12, 2014, at 7:40 AM, Alan Lawrence <alan.lawre...@arm.com> wrote: > > > > (It is no more expensive.) > > Yes on some processors it could be.
Haven't we been here before [1]? This disparaging mechanism is still not going to give what we are trying to achieve (assigning cost at the -mcpu/-mtune level, rather than the target level). Recall that '!' gives a static cost of 600 [2] and that this cost is only applied to the alternative if any operand in that alternative needs reloading - otherwise, LRA sees a set of matching operands and does not bother checking costs [3]. IRA, as far as I can see, does not care about '!', but unconditionally adds 2 to the cost of an alternative for '?' [4]. Even if LRA did try to do a more complete job of always picking the alternative with lowest cost (rather than the current first-matching behaviour) "600" would be far too high a cost for the operation. If IRA took '!' into account, we would be as well to remove the alternative entirely. So, I still can't agree that we want these exclamation marks - and we are now in a halfway state where some instructions have them and some don't. We have to pick a consistent policy or we are going to see some very poor code generation. In an ideal world, we would have a sensible way of describing a (per-core granularity) alternative cost, which would be considered by the register allocators. I've played about with doing this using attributes, but it ends up as a messy patch and I can't bring myself to add yet another cost framework to the back end. Do you have any ideas as to how we can make some progress? Maybe Vladimir has some suggestions? Thanks, James [1] https://gcc.gnu.org/ml/gcc-patches/2014-03/msg01627.html [2] regoc.c::preprocess_constraints [3] I may have misread this, but that seems to be what the final condition of the main loop of lra-constraints::process_alt_operands implies. [4] ira-costs.c::record_reg_classes
