Re: [match.pd] Fix for PR35691

[Prathamesh Kulkarni <prathamesh dot kulkarni at linaro dot org>]

On 4 November 2016 at 13:41, Richard Biener <rguenther@suse.de> wrote:
> On Thu, 3 Nov 2016, Marc Glisse wrote:
>
>> On Thu, 3 Nov 2016, Richard Biener wrote:
>>
>> > > > > 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.
>>
>> Oups, that's what I had written first, and then I somehow managed to confuse
>> myself enough to remove it so as to remove the call to types_match :-(
>>
>> > > 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.
>>
>> Oh, right, I keep forgetting that :-( And I have no idea how to generate one
>> for a testcase, at least until the GIMPLE FE lands...
>>
>> > > 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.
>>
>> Would that generate sensible code on targets that do not have logic insns for
>> floats? Actually, even on x86_64 that generates inefficient code, so there
>> would be some work (for instance grep finds no gen_iordf3, only gen_iorv2df3).
>>
>> I am also a bit wary of doing those obfuscating optimizations too early...
>> a==0 is something that other optimizations might use. long
>> c=(long&)a|(long&)b; (double&)c==0; less so...
>>
>> (and I am assuming that signaling NaNs don't make the whole transformation
>> impossible, which might be wrong)
>
> Yeah.  I also think it's not so much important - I just wanted to mention
> vectors...
>
> Btw, I still think we need a more sensible infrastructure for passes
> to gather, analyze and modify complex conditions.  (I'm always pointing
> to tree-affine.c as an, albeit not very good, example for handling
> a similar problem)
Thanks for mentioning the value-matching capture @@, I wasn't aware of
this match.pd feature.
The current patch keeps it restricted to only bitwise operators on integers.
Bootstrap+test running on x86_64-unknown-linux-gnu.
OK to commit if passes ?

Thanks,
Prathamesh
>
> Richard.

Attachment: 35691-2.txt
Description: Text document