On Apr 2, 2013, at 1:55 AM, Eric Botcazou wrote:
> The question is: do we really need to canonicalize everything?
> 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.
My t
On 04/02/2013 04:54 AM, Eric Botcazou wrote:
I wonder if those issues might in most cases be bugs in the back-ends
(optimizations missed depending on the order), that the canonicalization
would make more noticable (and thus easier to fix).
There are certainly such issues in the back-ends (and e
> I can, but then I am giving lshift higher priority than every other
> operation, not just rshift. And if I want to give (vec_select x 0) a
> higher precedence than (vec_select x 1) but lower than (vec_select
> (vec_concat a b) 1), the weights may become complicated, whereas the
> comparison funct
On Tue, 2 Apr 2013, Eric Botcazou wrote:
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?
> 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
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 recurs
> 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 i
