From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129061 invoked by alias); 27 Jul 2019 09:22:54 -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 129049 invoked by uid 89); 27 Jul 2019 09:22:53 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=strategies, H*Ad:U*rguenther, HX-Languages-Length:1687 X-HELO: mail-io1-f67.google.com Received: from mail-io1-f67.google.com (HELO mail-io1-f67.google.com) (209.85.166.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 27 Jul 2019 09:22:52 +0000 Received: by mail-io1-f67.google.com with SMTP id f4so109856163ioh.6 for ; Sat, 27 Jul 2019 02:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8m+GyOuHgWIUxqqmaVsYINRgvv8T43MBIO+OJ+VsiUY=; b=k3wen1cl80kAYS2/wN2kF4cHMzDT2+ZbZtMDGpBe19kSZWAcNG7QT/p0BIzDsZ4Xlu hfGaE0UPEJxnQY2uu7JnXVRk9ysXWymMkIISaYOCSVaUbee04JK9I4NdtLGoJ3/KY48b LaHMDwNEe35CspDlW3Pz8TXujSB1WX6ngVrj4iMke2H6Ry2M18YsgjqiOSokEZ7hiXyB Isc+oEf2c45lsc4N6g6X3ztKdhIGdB/TzuiAsns/O39aqssUDAW4Pc3hiemzO3zj5taJ C5iNO6PnB5QT9EHT662hEVed4h3sV3FbN4mR5tUeBX//+qYcQaNiCok5jpfRzUAPoj+y 9ENg== MIME-Version: 1.0 References: In-Reply-To: From: Uros Bizjak Date: Sat, 27 Jul 2019 10:07:00 -0000 Message-ID: Subject: Re: [PATCH][RFC][x86] Fix PR91154, add SImode smax, allow SImode add in SSE regs To: Jeff Law Cc: Richard Biener , "gcc-patches@gcc.gnu.org" , Jan Hubicka , Kirill Yukhin , Vladimir Makarov , "H. J. Lu" , Martin Jambor Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2019-07/txt/msg01697.txt.bz2 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 am indeed surprised that the perception of the developers is that STV doesn't work. Maybe I'm missing something obvious here? (*) The infrastructure includes: - cost analysis of the whole STV chain, including moves from integer registers, loading and storing DImode values - preloading of arguments into vector registers to avoid duplicate int-vec moves - different strategies to move arguments between int and vector registers (e.g. respects TARGET_INTER_UNIT_MOVES_{TO,FROM}_VEC flag) Uros.