Re: [match.pd] Fix for PR35691

[Marc Glisse <marc dot glisse at inria dot fr>]

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)

--
Marc Glisse