Canonicalize X u< X to UNORDERED_EXPR

[Richard Biener]

On Tue, May 3, 2016 at 3:26 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
> On Tue, 3 May 2016, Richard Biener wrote:
>
>> On Tue, May 3, 2016 at 8:36 AM, Marc Glisse <marc.glisse@inria.fr> wrote:
>>>
>>> This removes the duplication. I also removed the case (A&B)&(A&C) which
>>> is
>>> handled by reassoc. And I need 2 NOP checks, for the case where @0 is a
>>> constant (that couldn't happen before my patch because canonicalization
>>> would put the constant as second operand).
>>
>>
>> Nicely spotted.  Not sure we want to delay (A&B)&(A&C) until re-assoc.  We
>> have
>> many patterns that reassoc would also catch, like (A + CST) + CST or (A +
>> B)- A,
>> albeit reassoc only handles the unsigned cases.
>
>
> (A&B)&A seems simple enough for match.pd, I thought (A&B)&(A&C) was starting
> to be a bit specialized. I could easily add it back (making it work with |
> at the same time), but then I am not convinced A&(B&C) is the best output.
> If A&B or A&C have several uses, then (A&B)&C or B&(A&C) seem preferable
> (and we would still have a transformation for (A&cst1)&cst2 so we wouldn't
> lose in the case where B and C are constants). We may still end up having to
> add some :s to the transformation I just touched.

Yeah, these are always tricky questions.  Note that re-assoc won't
handle the case
with multi-use A&C or A&B.  The only reason to care for the single-use case is
when we change operations for the mixed operand cases.  For the all-&| case
there is only the (usual) consideration about SSA lifetime extension.

So maybe it makes sense to split out the all-&| cases.

Richard.

> --
> Marc Glisse