From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 690E339450E7; Fri, 27 Mar 2020 08:45:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 690E339450E7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1585298742; bh=BwX8qfe98qBndUgzOOZ1Fpmf/mUHQs08joUpfYxce1c=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Y2CHPuEpIoxi8RHN0wibfuLGmUAXEVaYzbmwP27D1Ao/+FBgwGXW/ivJo0c2SCF2B sVYP4bkojuVnxNum88ZGaYrqwGz+bLlTkvSxjy6/Pra2kmJxAVMzH2qY+x9r08Y9so lTO7EOH4cUxyrog5RTkMyPIKOAblC2tPvqN06R28= 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 08:45:42 +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 08:45:42 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94343 --- Comment #14 from Jakub Jelinek --- (In reply to jbeulich from comment #13) > As to using 512-bit operations even on more narrow input types - is this > correct when e.g. subsequently source code upcasts the vector? I.e. would > such an upcast be carried out by emitting an insn to zero the upper porti= on, > rather than simply considering this a re-interpretation of the same regis= ter > (with no insn emitted at all)? In which case the fix would apparently boil > down to using a mode iterator different from VI (VI48_AVX512VL if you rea= lly > mean to exclude vectors of QI/HI, or a combination of this and VI12_AVX51= 2VL > otherwise). Yes, in RTL a store to a register in some machine mode when the hw register= has wider mode leaves the upper bits undefined, not zero initialized (like e.g. most of the 32-bit instructions do on 64-bit general purpose registers or m= any AVX etc. instructions do on vector registers), we do have a REE pass to han= dle some most common cases. If we added some machine specific pass that would do something like that for most instructions, we'd need some attribute to mark instructions that don't have that property, sure, but we don't ATM.=