On Sun, Jun 25, 2023 at 1:52 PM Jan Beulich <jbeul...@suse.com> wrote: > > On 25.06.2023 06:42, Hongtao Liu wrote: > > On Wed, Jun 21, 2023 at 2:26 PM Jan Beulich via Gcc-patches > > <gcc-patches@gcc.gnu.org> wrote: > >> > >> +(define_code_iterator andor [and ior]) > >> +(define_code_attr nlogic [(and "nor") (ior "nand")]) > >> +(define_code_attr ternlog_nlogic [(and "0x11") (ior "0x77")]) > >> + > >> +(define_insn "*<nlogic><mode>3" > >> + [(set (match_operand:VI 0 "register_operand" "=v,v") > >> + (andor:VI > >> + (not:VI (match_operand:VI 1 "bcst_vector_operand" "%v,v")) > >> + (not:VI (match_operand:VI 2 "bcst_vector_operand" "vBr,m"))))] > > I'm thinking of doing it in simplify_rtx or gimple match.pd to transform > > (and (not op1)) (not op2)) -> (not: (ior: op1 op2)) > > This wouldn't be a win (not + andn) -> (or + not), but what's > more important is ... > > > (ior (not op1) (not op2)) -> (not : (and op1 op2)) > > > > Even w/o avx512f, the transformation should also benefit since it > > takes less logic operations 3 -> 2.(or 2 -> 2 for pandn). > > ... that these transformations (from the, as per the doc, > canonical representation of nand and nor) are already occurring I see, there're already such simplifications in the gimple phase, so the question: is there any need for and/ior:not not pattern? Can you provide a testcase to demonstrate that and/ior: not not pattern is needed? > in common code, _if_ no suitable insn can be found. That was at > least the conclusion I drew from looking around a lot, supported > by the code that's generated prior to this change. > > Jan
-- BR, Hongtao
