[Bug target/100711] Miss optimization for pandn

["crazylht at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100711

--- Comment #3 from Hongtao.liu <crazylht at gmail dot com> ---


(In reply to Segher Boessenkool from comment #2)
> (In reply to Richard Biener from comment #1)
> > I suppose we're confused about the vec_duplicate.  Would generally swapping
> > the duplicate and the bit_not be profitable?  Eventually it's a
> > simplification
> > combine could try - I belive it has some cases where it tries variants of the
> > original instructions when combining.  Adding a combine helper pattern
> > looks like putting too much burden on the backend IMHO.
> > 
> > We don't have a generic nand optab so handling this in ISEL on gimple
> > isn't straight-forward.
> > 
> > But combine and/or forwprop could do this.
> 
> Combine never tries anything.  Combine makes *one* result; if that does not
> work,
> it does not do the combination.  (This is not completely true, but in essence
> that is how it works, and it has to to not have exponential complexity).
> 
> It would be good to define a canonical form for anything vec_duplicate.  It
> probably is a good idea to pull the vec_duplicate as far outside as possible?
> 
> Canonical forms hugely reduce the amount of work needed.  Compare to how
> "andc"
> is represented (canonically with the inverted input first), or how "nand" is
> (we
> write that as an "orcc", an "or" with both inputs inverted, in canonical
> RTL).
> Because only one form is allowed, we only have to check for that one form
> everywhere.
> 
> Confirmed.

Even w/ canonical RTL, i think a combine splitter is also needed here, the
canonical RTL only helps combine/forwprop to match more possibility but won't
split patterns by itselies.