From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56539 invoked by alias); 9 Aug 2019 22:03:46 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 56531 invoked by uid 89); 9 Aug 2019 22:03:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=multilib, releases X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Aug 2019 22:03:45 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 78EC0308FFB1; Fri, 9 Aug 2019 22:03:44 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-27.rdu2.redhat.com [10.10.112.27]) by smtp.corp.redhat.com (Postfix) with ESMTP id 39F3A60872; Fri, 9 Aug 2019 22:03:41 +0000 (UTC) Subject: Re: [PATCH][RFC][x86] Fix PR91154, add SImode smax, allow SImode add in SSE regs To: Uros Bizjak Cc: Richard Biener , "gcc-patches@gcc.gnu.org" , Jan Hubicka , Kirill Yukhin , Vladimir Makarov , "H. J. Lu" , Martin Jambor References: From: Jeff Law Openpgp: preference=signencrypt Message-ID: Date: Fri, 09 Aug 2019 22:15:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00663.txt.bz2 On 7/27/19 3:22 AM, Uros Bizjak wrote: > On Wed, Jul 24, 2019 at 5:03 PM Jeff Law wrote: > >>> Clearly this approach will run into register allocation issues >>> but it looks cleaner than writing yet another STV-like pass >>> (STV itself is quite awkwardly structured so I refrain from >>> touching it...). >>> >>> Anyway - comments? It seems to me that MMX-in-SSE does >>> something very similar. >>> >>> Bootstrapped on x86_64-unknown-linux-gnu, previous testing >>> revealed some issue. Forgot that *add_1 also handles >>> DImode..., fixed below, re-testing in progress. >> Certainly simpler than most of the options and seems effective. >> >> FWIW, I think all the STV code is still disabled and has been for >> several releases. One could make an argument it should get dropped. If >> someone wants to make something like STV work, they can try again and >> hopefully learn from the problems with the first implementation. > > Huh? > > STV code is *enabled by default* on 32bit SSE2 targets, and works > surprisingly well (*) for DImode arithmetic, logic and constant shift > operations. Even 32bit multilib on x86_64 is built with STV. I must be mis-remembering or confusing it with something else. Sorry for any confusion. Jeff