Re: RFC: Combine of compare & and oddity

[Segher Boessenkool <segher@kernel.crashing.org>]

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