From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3774 invoked by alias); 18 Dec 2013 09:50:30 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 3734 invoked by uid 48); 18 Dec 2013 09:50:27 -0000 From: "ubizjak at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/59539] Missed optimisation: VEX-prefixed operations don't need aligned data Date: Wed, 18 Dec 2013 09:50:00 -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: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ubizjak at gmail dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- 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-SW-Source: 2013-12/txt/msg01622.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D59539 --- Comment #5 from Uro=C5=A1 Bizjak --- (In reply to Jakub Jelinek from comment #4) > > From a quick look at the patch, the proposed patch doesn't support mask= ed > > insns.=20 > >=20 > > I think it is better to introduce corresponding sse.md expanders for > > UNSPEC_STOREU and UNSPEC_LOADU insns. These expanders will either gener= ate > > UNSPEC_* pattern or "normal" (masked) move in case of TARGET_AVX. >=20 > I can surely add the expanders, but don't understand the comment about > masked moves. *maskload* is already a specialized UNSPEC, and can't real= ly > be merged with arithmetic patterns (ok, perhaps with -mavx512f?) and hand= les > both aligned and unaligned operands the same. Ah, sorry for being terse, I was looking at avx512f_storeu_..._mask. I assu= me that this pattern can be combined as a memory operand into other SSE instructions, in the same way as non-masked UNSPEC_* patterns. Admittedly, = we are in the middle of avx512f merge, so this assumption may be wrong. >>From gcc-bugs-return-437968-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Dec 18 09:52:00 2013 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 4766 invoked by alias); 18 Dec 2013 09:52:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 4714 invoked by uid 48); 18 Dec 2013 09:51:56 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/58668] [4.8/4.9 regression] internal compiler error: in cond_exec_process_insns, at ifcvt.c:339 Date: Wed, 18 Dec 2013 09:52:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 4.8.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-12/txt/msg01623.txt.bz2 Content-length: 1692 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58668 --- Comment #7 from Jakub Jelinek --- (In reply to Eric Botcazou from comment #6) > > I think the problem is that ifcvt relies on consistent counting of insns, > > but the various functions count different things. > > What kind of insns is responsible for the discrepancy that leads to the ICE? On the given testcase the JUMP_INSN at the end of bb is returnjump_p (without additional side effects), so it isn't counted and thus that problem isn't present. But the problem on the testcase is insn with USE pattern right before the jump, count_bb_insns counts it as active insn, flow_find_cross_jump doesn't, and we subtract from the former the latter to see how many insns we should allow at most for flow_find_head_matching_sequence, and because of the discrepancy it is one bigger than it should and we end up with then_last_head being after then_end, which violates the assumptions the code makes. > > 3) perhaps not count USE/CLOBBER insns in flow_find_head_matching_sequence if > > stop_after is non-zero? > > I'd first make the functions behave the same wrt USE and CLOBBER insns. Perhaps we can ignore those always in flow_find_head_matching_sequence? > > 4) perhaps add also skip_use argument to first_active_insn and if TRUE, > > ignore USE insns and for both {first,last}_active_insn if skip_use is TRUE, > > also ignore CLOBBER insns > > > > 5) in find_active_insn_{before,after} ignore USE/CLOBBER insns > > and document this properly? > > I'm less sure about these ones: does their behavior need to be in keeping > with the insns counting? Perhaps, though I'd say it might be a ticking bomb.