https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100711
Segher Boessenkool <segher at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed| |2021-05-21
--- Comment #2 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(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.
