From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60822 invoked by alias); 5 Sep 2017 15:47:58 -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 60812 invoked by uid 89); 5 Sep 2017 15:47:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-ua0-f174.google.com Received: from mail-ua0-f174.google.com (HELO mail-ua0-f174.google.com) (209.85.217.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 05 Sep 2017 15:47:52 +0000 Received: by mail-ua0-f174.google.com with SMTP id c27so9115395uah.2 for ; Tue, 05 Sep 2017 08:47:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xBnWC9kKLgdWt4MVle0QfLnQfmj1aBcHHftY+RZwkgc=; b=L0LL98A0S667N+VNxTsCklfE69YLT7M6pIRr4QqKPgOJVwB/pXLuQs+yNmHEEACFpD h2t7bpNrW5x2hs0uyy6zQZKr9/mXLsqoB7kUCs8Gb93R1sLSY56aintFZN+7eQeuzm5X 6VUzAx5fshlxamHSMP0vA8ptNjhOBAXaGO8aSPiUzziyFoWJZQ8jnmGGYjnQhoEU0Ouv 3QSzu2wZ05OVHqF7MMhxpTA0+yUCZD/O9km6m/Iw8Ei6PC1ZucGEDGt7xLSMto82Mwng uOcNzkmu6l/Xo2w5WbpmUx9b+jrG+UFsk9bhnzkMN47/9xdtjQNJ3ZiTqYTOxM3VuB80 MPag== X-Gm-Message-State: AHPjjUiDnb/W9V/Ym1cd37Wkr/FJIAgxaGZ7TiozvJNiqUdOYpafn58o 736ePwaf6UDz0ipqxBydu/RJes6lQ9x0 X-Google-Smtp-Source: ADKCNb5TNqphDPRJNBcfRrevG6qjf1l8tF0Ayf6LV78oJRtv+6GkeV06A7cHBXGQyT4YWlATQQg+GLrAppDVlysjQaU= X-Received: by 10.159.59.164 with SMTP id r36mr2946895uah.169.1504626470570; Tue, 05 Sep 2017 08:47:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.81.3 with HTTP; Tue, 5 Sep 2017 08:47:49 -0700 (PDT) In-Reply-To: References: From: Christophe Lyon Date: Tue, 05 Sep 2017 15:47:00 -0000 Message-ID: Subject: Re: [PING][PATCH 2/3] retire mem_signal_fence pattern To: Uros Bizjak Cc: Alexander Monakov , "gcc-patches@gcc.gnu.org" , Jeff Law , "H. J. Lu" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00280.txt.bz2 Hi, On 5 September 2017 at 13:40, Uros Bizjak wrote: > On Tue, Sep 5, 2017 at 12:28 PM, Alexander Monakov wrote: >> On Mon, 4 Sep 2017, Uros Bizjak wrote: >>> introduced a couple of regressions on x86 (-m32, 32bit) testsuite: >>> >>> New failures: >>> FAIL: gcc.target/i386/pr71245-1.c scan-assembler-not (fistp|fild) >>> FAIL: gcc.target/i386/pr71245-2.c scan-assembler-not movlps >> >> Sorry. I suggest that the tests be XFAIL'ed, the peepholes introduced in the >> fix for PR 71245 removed, and the PR reopened (it's a missed-optimization PR). >> I can do all of the above if you agree. >> >> I think RTL peepholes are a poor way of fixing the original problem, which >> actually exists on all targets with separate int/fp registers. For instance, >> trunk (without my patch) still gets a far simpler testcase wrong (-O2, 64-bit): > > Please note that 32bit x86 implements atomic DImode access with > fild/fistp combination, so the mentioned peephole avoids quite costly > instruction sequence. > > For reference, attached patch implements additional peephole2 patterns > that also handle sequences with blockages. > > Uros. On arm, we also have a similar regression: FAIL: gcc.target/arm/stl-cond.c scan-assembler stlne Before the patch, we generated: ldr r3, [r0] cmp r3, #0 addne r3, r0, #4 movne r2, #0 stlne r2, [r3] bx lr and now: ldr r3, [r0] cmp r3, #0 bxeq lr mov r2, #0 add r3, r0, #4 stl r2, [r3] bx lr Christophe