> 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.

The question is: do we really need to canonicalize everything?  The more you 
canonicalize, the more internal shuffling you will get in the middle-end for a 
practical benefit that might be elusive in most cases.

> 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.

Why?  Can't you give them precedences in commutative_operand_precedence that 
preserve the transitivity?

> 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).

The fear (at least mine) is that, by canonicalizing everything, you will make 
changes behind the back of back-ends that could disable some of their patterns 
silently.  This is also a concern for new canonicalization rules, but at least 
you can reasonably audit the back-ends for every new rule.

> 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.

No, of course, canonicalization is desirable.

> 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?

I think that the current interface makes it clear that you need to tweak the 
precedence in order to change the canonicalization (thus preserving the 
transitivity).  Btw, there is something to fix in the head comment of 
commutative_operand_precedence because I cannot make sense of it.

-- 
Eric Botcazou

Reply via email to