On Thu, Sep 03, 2015 at 07:53:12PM +0100, Wilco Dijkstra wrote: > > > >>You will end up with a *lot* of target hooks like this. It will also > > > >>make testing harder (less coverage). I am not sure that is a good idea. > > > > > > > >We certainly need a lot more target hooks in general so GCC can do the > > > >right thing > > > >(rather than using costs inconsistently all over the place). But that's a > > > >different > > > >discussion... > > > Let's be very careful here, target hooks aren't always the solution. > > > I'd rather see the costing models fixed and use those across the board. > > > But frankly, I don't know how to fix the costing models. > > > > Combine doesn't currently use costs to decide how to simplify and > > canonicalise things. Simplifications are what is simpler RTL; combine's > > job is to make fewer RTL instructions (which is not the same thing as > > fewer machine instructions, or cheaper instructions). Changing what is > > canonical based on target hooks would be, uh, interesting. > > Would it be reasonable to query the rtx_cost of a compare+and and if the cost > is the same as an AND assume that that instruction does not need to be > "improved" > into the canonical form? That way it will use the compare+and pattern if it > exists > and still try the zero_extract/shift+and forms for targets that don't have a > compare+and instruction.
At the point the canonicalisation is done you do not yet know if this is a valid instruction at all. Introducing more cost computations for random things is not such a great idea, and for RTL that can never be part of a machine instruction doubly so. I think we really should just change what is the canonical form for such a comparison. Segher
