Re: [RTL] Canonicalize commutative operations more

[Marc Glisse <marc.glisse@inria.fr>]

On Wed, 27 Mar 2013, Eric Botcazou wrote:

>> This patch passes bootstrap+testsuite on x86_64-linux-gnu. Using the
>> opposite arbitrary order in compare_commutative_operands_precedence
>> (exchange x and y in the line with GET_CODE) passes as well. The
>> simplify-rtx bit is because I get an infinite recursion otherwise.
>> Surprisingly, that infinite recursion occurs only in var-tracking, and
>> only for a single file in bootstrap+testsuite (not the same one depending
>> on the arbitrary order). I am not sure that is the best place to break the
>> recursion, but it seems to work.
>>
>> I don't really expect the patch to be accepted as is, but it seems good
>> enough to start the conversation.
>
> I'm rather with Jakub here, I think that arbitrary canonicalization as the one
> proposed here will probably be worse than no canonicalization in practice,
> because it will generate much shuffling.  If you need more canonicalization,
> then why not propose new, precise canonicalization rules?

Well, the goal was to have arbitrary canonicalization for all cases where 
precise rules are not already provided. In (a<<8)|(b>>24), there is no 
obvious reason why lshift should have higher or lower priority than 
rshift, but we don't want to have to write patterns with both orders in 
the target .md files. In v[0]+v[1] (v is a V2DF), it is likewise 
preferable if we know in which order the operands will appear, but I don't 
care what that order is (note that ordering this one requires a refinement 
that I didn't include in this first version of the patch). And this way we 
don't have to refine the order all the time, we just check what order this 
arbitrary rule generates and write the pattern accordingly.

I am not sure about adding just a few rules. If I just say that lshift is 
stronger than rshift, the relation is not an order (transitive) anymore. 
And it might already have some of the drawbacks you and Jakub fear (I 
don't have a good understanding of those, I may be wrong).

If there is a nice way to instead try permutations (note that for a 
pattern involving k commutative operations, there are 2^k versions), I am 
just as happy with that.

By the way, even if we don't take the canonicalization (just ignore the 
line comparing GET_CODEs), do we still want the refactoring that this 
patch brings, or is the current interface better?

-- 
Marc Glisse