On Thu, Jul 23, 2015 at 10:09:49AM -0600, Jeff Law wrote: > It seems to me in these kind of cases that selection of the canonical > form should be driven by factors outside of which is better for a > particular target. ie, which is simpler
I agree. But neither form is simpler here, and we need to have both forms in other contexts, so there is no real benefit to canonicalising. > Instead we should be looking at the gimple->rtl expansion phase to > expand using a form that is better for a particluar target. > > [And yes, I think I've violated this new guiding principle in the past] > > Given the (a << n) EQ/NE form, can we reasonably detect this in the > gimple->expansion phase and emit code as if we had the alternate form > for targets such as aarch64? In gimple, both forms have the same complexity as far as I see. In RTL both forms have the same complexity as well. RTX cost can be higher for the AND form (or, in theory at least, can be lower for some targets). In my opinion expand shouldn't do anything special here, just emit RTL like the gimple it is fed, and let the target deal with it, or the generic RTL optimisers. Or do we have an example where that does not work or is inconvenient? Segher
