From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F1FDA39450F4; Fri, 27 Mar 2020 09:11:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F1FDA39450F4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1585300306; bh=VOSii9uLo3ZJxcxyBX5aEvBMbpUgfhCO1bztv2skFKU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=LKv9V1aQ7hQHkhW1OKbr95MQ4FFpxyHJn39KDcojNbidjv8QOhZik9t/gs69TjgN5 dowd3x+sIeABJ5nmz56wEcNWsUR3R/0/IIRtCvgU9ZHQxC1jd/l73I76yvWCjex6qk KHaa3aF7ZZCIDdTgarxBOiRMtb5GSgy0vT/FZlkE= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl Date: Fri, 27 Mar 2020 09:11:46 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: missed-optimization, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 09:11:47 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94343 --- Comment #15 from Jakub Jelinek --- (In reply to jbeulich from comment #11) > (In reply to Jakub Jelinek from comment #7) > > Though, there are other issues. There is only vpternlog{d,q}, so for > > V*[QH]Imode we shouldn't pretend we have masking support. >=20 > Why would this be? The element mode doesn't matter at all for bitwise > operations. Just like there's no VPANDB / VPANDW, but VPANDD/VPANDQ are > quite fine to use on vectors of QI or HI. Afaict the existence of VPAND{D= ,Q} > in AVX512 (as opposed to {,V}PAND in MMX/SSE2/AVX) is merely an oddity > resulting from EVEX.W handling (besides of course the element width's eff= ect > on embedded broadcasting). For masked instructions, the element mode is significant, it determines whi= ch bits of the mask register apply to which bits in the destination register. So, if the masked variant is ever matched (e.g. by combine), then it will expect to do something different from what the insn will actually do. (define_insn ("one_cmplv64qi2_mask") [ (set (match_operand:V64QI 0 ("register_operand") ("=3Dv")) (vec_merge:V64QI (xor:V64QI (match_operand:V64QI 1 ("nonimmediate_operand") ("vm")) (match_operand:V64QI 2 ("vector_all_ones_operand") ("BC= "))) (match_operand:V64QI 3 ("nonimm_or_0_operand") ("0C")) (match_operand:DI 4 ("register_operand") ("Yk")))) ] ("(TARGET_AVX512F) && ((TARGET_AVX512F) && (TARGET_AVX512BW))") ("vpternlogd\t{$0x55, %1, %0, %0%{%4%}%N3|%0%{%4%}%N3, %0, %1, 0x55}") [ (set_attr ("type") ("sselog")) (set_attr ("prefix") ("evex")) (set_attr ("mode") ("XI")) (set_attr ("mask") ("no")) ]) The above says in RTL that for say the last operand of 0x5555555555555555UL= L, first 8 bits in the vector will be the result of the ternlog operation, nex= t 8 bits will be cleared or unmodified (depending on operand 3), etc. The instruction used for that will do something different, will ignore the upper 48 bits of the mask register and the low 32 bits of the destination w= ill be the result of the ternlog operation, next 32 bits will be cleared or unmodified, etc.=