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.
