From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BA92F395CC4E; Thu, 14 May 2020 13:41:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BA92F395CC4E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1589463674; bh=aj28QHtIR+OYjFCTO5bGC7+bEhGjhCsAJ8ZZBNz37jQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=eNwYU/zdD22Vek30ZrsiWymtaOzxTdqHjk6lbEU/jlVkrdUhfge+jKKee8BEHb+NV /7mIlbzh0MDh6jRhI+wDhKj+8+FwsaqcaYJOmvOyzE/JkvMlLNFx+oe/ZTLW6WIgke cxl80MZMFRRNi3lIxi6J3FCjUTFMR52LYR1xPmAE= From: "rsandifo at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/92658] x86 lacks vector extend / truncate Date: Thu, 14 May 2020 13:41:14 +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 X-Bugzilla-Severity: normal X-Bugzilla-Who: rsandifo at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ubizjak at gmail dot com 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-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: Thu, 14 May 2020 13:41:14 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92658 --- Comment #12 from rsandifo at gcc dot gnu.org --- (In reply to rguenther@suse.de from comment #11) > On Thu, 14 May 2020, ubizjak at gmail dot com wrote: >=20 > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92658 > >=20 > > --- Comment #10 from Uro=C5=A1 Bizjak --- > > The patch is ready to be pushed, it is waiting for a decision what to d= o with > > failed cases. > >=20 > > Richi, should this patch move forward (eventually XFAILing failed cases= ), or do > > you plan to look at the fails from the generic vectorizer POV? >=20 > I think we should go forward with the patch, either XFAILing the testcases > or splitting out the testcase (and backend patterns that do not get > exercised due to the issue). >=20 > I've already said in comment#8 that the issue here is optabs working > with modes and not vector types, so it's a bit hard to use the > same mechanism to deal with the currently failing cases. One > possible route would be to add V4QImode similar to how we now > do V2SFmode with SSE but of course where do we stop ... >=20 > As said we can try to tackle this incrementally. Maybe Richard also > has input here? Nothing to add really, but: yeah, the idea was that the target would provide smaller vector modes if it can efficiently load, store and (at least) add them. I think it would be good to do that for aarch64 Advanced SIMD at some point. There are three points behind using vector modes for this: 1. It gives the target the flexibility to decide how best to implement the operation (All at one end, and if so, which end? Or spread out evenly across the vector?) On aarch64, the choice would differ between SVE and Advanced SIMD. 2. It means that __attribute__((vector_size)) vectors benefit. 3. The smaller modes can be used in conjunction with autovectorize_vector_modes to give the loop vectoriser a choice between operating on packed or unpacked vectors. This is mostly useful for VECT_COMPARE_COSTS but can help with low-trip-count loops even without. So yeah, defining V4QI sounds like the way to go if the architecture can process it efficiently. I get the "where do we stop" concern, but .md mode iterators should help.=