This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [match.pd] Fix for PR35691
On November 3, 2016 6:11:07 PM GMT+01:00, Marc Glisse <marc.glisse@inria.fr> wrote:
>On Thu, 3 Nov 2016, Prathamesh Kulkarni wrote:
>
>> On 3 November 2016 at 16:13, Richard Biener <rguenther@suse.de>
>wrote:
>>> On Thu, 3 Nov 2016, Prathamesh Kulkarni wrote:
>>>
>>>> Hi Richard,
>>>> The attached patch tries to fix PR35691, by adding the following
>two
>>>> transforms to match.pd:
>>>> (x == 0 && y == 0) -> (x | typeof(x)(y)) == 0.
>>>> (x != 0 || y != 0) -> (x | typeof(x)(y)) != 0.
>>>>
>>>> For GENERIC, the "and" operator is truth_andif_expr, and it seems
>for GIMPLE,
>>>> it gets transformed to bit_and_expr
>>>> so to match for both GENERIC and GIMPLE, I had to guard the
>for-stmt:
>>>>
>>>> #if GENERIC
>>>> (for op (truth_andif truth_orif)
>>>> #elif GIMPLE
>>>> (for op (bit_and bit_ior)
>>>> #endif
>>>>
>>>> Is that OK ?
>>>
>>> As you are not removing the fold-const.c variant I'd say you should
>>> simply not look for truth_* and only handle GIMPLE. Note that we
>>> have tree-ssa-ifcombine.c which should handle the variant with
>>> control-flow (but I guess it does not and your patch wouldn't help
>>> it either).
>>>
>>> The transform would also work for vectors (element_precision for
>>> the test but also a value-matching zero which should ensure the
>>> same number of elements).
>> Um sorry, I didn't get how to check vectors to be of equal length by
>a
>> matching zero.
>> Could you please elaborate on that ?
>
>He may have meant something like:
>
> (op (cmp @0 integer_zerop@2) (cmp @1 @2))
I meant with one being @@2 to allow signed vs. Unsigned @0/@1 which was the point of the pattern.
>So the last operand is checked with operand_equal_p instead of
>integer_zerop. But the fact that we could compute bit_ior on the
>comparison results should already imply that the number of elements is
>the
>same.
Though for equality compares we also allow scalar results IIRC.
This would also prevent the case where one vector is signed and
>the
>other unsigned, which requires a view_convert (I don't remember if
>convert
>automatically becomes view_convert here as in fold_convert or not).
No, but the other way around (for sign changes).
>For (some_int == 0) & (some_long == 0), doing ((long)some_int |
>some_long)
>== 0 should also work (and it doesn't matter if we pick a sign- or
>zero-extension), but that's more complicated, not necessary for a first
>
>version.
Yeah.
>On platforms that have IOR on floats (at least x86 with SSE, maybe some
>
>vector mode on s390?), it would be cool to do the same for floats (most
>
>likely at the RTL level).
On GIMPLE view-converts could come to the rescue here as well. Or we cab just allow bit-and/or on floats as much as we allow them on pointers.
Richard.