Re: RFC: Combine of compare & and oddity

[Jeff Law <law@redhat.com>]

On 09/03/2015 12:53 PM, Wilco Dijkstra wrote:
>> Segher Boessenkool wrote:
>> On Thu, Sep 03, 2015 at 10:09:36AM -0600, Jeff Law 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.
Perhaps -- but you also have to make sure that you don't regress cases 
where canonicalization in turn exposes simplifications due to related 
insns in the chain.

Jeff