From patchwork Tue Sep 3 07:08:32 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 1156852 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-508195-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="NZAQXwEO"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 46MyjV3dwNz9s00 for ; Tue, 3 Sep 2019 17:08:44 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:mime-version :content-type; q=dns; s=default; b=Yca2EB/a5vCjGob/0RRRr17vDcU3j aKHcVlzpFkZbdBR6P+AyP8pyDPXB/gFoOYF/zGLI58JAQyrLPHTlcGRZ5N4V7s1/ hbXDG9OYoX1jGs0jyJF5TcgHmY8dgS9J4xTNce5vF1/Ski4GrBXs/qVSdTuv6si6 UK5kxnAeDdAAPA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:mime-version :content-type; s=default; bh=KzDu/KsB8jqB3VUs/GQxvQYxkBY=; b=NZA QXwEOn8glri9S8S0Hnnqxd5ZaYxQBCdcm/bH2hTDZUG1gTH/YMB0dPih3G267OlI 8xRkfSpSSPqMyhYSbb9K7+vCdftHnmSd9ABQFO5MyDo6zg5Pz1L+zkbRroh3GDIj rVsuJ/+JJYbRJiJ/nAm1fq0WksYcfACmv3k3KU5M= Received: (qmail 121958 invoked by alias); 3 Sep 2019 07:08:38 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 121946 invoked by uid 89); 3 Sep 2019 07:08:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.5 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= 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; Tue, 03 Sep 2019 07:08:37 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A207E189DACF; Tue, 3 Sep 2019 07:08:35 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-139.ams2.redhat.com [10.36.116.139]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3AB605DA5B; Tue, 3 Sep 2019 07:08:35 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id x8378XCp004217; Tue, 3 Sep 2019 09:08:33 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id x8378WTb004216; Tue, 3 Sep 2019 09:08:32 +0200 Date: Tue, 3 Sep 2019 09:08:32 +0200 From: Jakub Jelinek To: Uros Bizjak Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Fix x86 double word splitting (PR target/91604) Message-ID: <20190903070832.GR2120@tucnak> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.11.3 (2019-02-01) X-IsSubscribed: yes Hi! As mentioned in the PR, adjust_address in certain cases forces the address into a register. This doesn't work if there is a matching MEM, where we need rtx_equal_p before the splitting as well as after the splitting. The following patch fixes that by checking for the matching MEM (looks just for one, that should be enough for x86 backend IMHO) and reusing the adjust_address results in that case instead of calling it again. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2019-09-03 Jakub Jelinek PR target/91604 * config/i386/i386-expand.c (split_double_mode): If there is more than one MEM operand and they are rtx_equal_p, reuse lo_half/hi_half from already split matching MEM operand instead of calling adjust_address again. * gcc.target/i386/pr91604.c: New test. Jakub --- gcc/config/i386/i386-expand.c.jj 2019-08-29 11:22:21.897593027 +0200 +++ gcc/config/i386/i386-expand.c 2019-09-02 18:31:10.362812352 +0200 @@ -106,6 +106,8 @@ split_double_mode (machine_mode mode, rt { machine_mode half_mode; unsigned int byte; + rtx mem_op = NULL_RTX; + int mem_num = 0; switch (mode) { @@ -129,8 +131,18 @@ split_double_mode (machine_mode mode, rt but we still have to handle it. */ if (MEM_P (op)) { - lo_half[num] = adjust_address (op, half_mode, 0); - hi_half[num] = adjust_address (op, half_mode, byte); + if (mem_op && rtx_equal_p (op, mem_op)) + { + lo_half[num] = lo_half[mem_num]; + hi_half[num] = hi_half[mem_num]; + } + else + { + mem_op = op; + mem_num = num; + lo_half[num] = adjust_address (op, half_mode, 0); + hi_half[num] = adjust_address (op, half_mode, byte); + } } else { --- gcc/testsuite/gcc.target/i386/pr91604.c.jj 2019-09-02 18:35:24.399989307 +0200 +++ gcc/testsuite/gcc.target/i386/pr91604.c 2019-09-02 18:32:29.409622762 +0200 @@ -0,0 +1,11 @@ +/* PR target/91604 */ +/* { dg-do compile } */ +/* { dg-options "-O3 -msse2 --param max-gcse-memory=0 -fno-rerun-cse-after-loop" } */ + +long long v; + +void +foo (void) +{ + v = ~v; +}