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
