On Tue, Sep 24, 2013 at 12:36 PM, Richard Earnshaw <rearn...@arm.com> wrote: > On 24/09/13 11:12, Richard Biener wrote: >> Or even [reg*scale] (not sure about that). But yes, at least reg*scale + >> offset >> and reg*scale + reg. > > I can't conceive of a realistic case where one would want to scale the > base address. Scaling the offset is fine, but never the base. So > reg*scale+offset seems meaningless. > > Base + Offset * Scale on the other hand makes much more sense. > > Of course, this is all about terminology, so if you regard an immediate, > such as a symbol as an offset, then perhaps you have something close to > the original term, but I think then you've inverted things, since your > symbol is really the base, not the offset.
Sure, this can't be the complete memory address - but that doesn't seem to be what IVOPTs is testing. Your example of $SYM + offset * scale is a good one for example. IVOPTs is merely asking whether it can use a scaled offset. That the present test doesn't work for arm hints at that it doesn't build up the correct RTL for the test, but also since this works for other targets which probably also don't only have a scaled offset without a base it isn't all that clear what a) the codes desire is, b) the correct solution is without regressing on other targets. Btw, it should be reasonably possible to compute the whole multiplier_allowed_in_address_p table for all primary and secondary archs (simply build cross-cc1) and compare the results before / after a patch candidate. Querying both reg * scale and reg + reg * scale if the first fails sounds like a good solution to me. Richard. > R. >
