From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32547 invoked by alias); 16 Apr 2019 15:08: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 32532 invoked by uid 89); 16 Apr 2019 15:08:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 spammy=detect, HContent-Transfer-Encoding:8bit X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 16 Apr 2019 15:08:43 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x3GF8fl9025775; Tue, 16 Apr 2019 10:08:41 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x3GF8eaL025774; Tue, 16 Apr 2019 10:08:40 -0500 Date: Tue, 16 Apr 2019 15:10:00 -0000 From: Segher Boessenkool To: Roman Zhuykov Cc: gcc-patches@gcc.gnu.org, Jakub Jelinek Subject: Re: [4/4][PATCH] Discussing PR83507 Message-ID: <20190416150840.GC8599@gate.crashing.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00647.txt.bz2 On Tue, Apr 16, 2019 at 03:08:23PM +0300, Roman Zhuykov wrote: > This issue unfortunately was not solved correctly. In that example we > don’t have -fmodulo-sched-allow-regmoves enabled and we should not > create any register moves at all. Yes, but if we do for whatever reason, we should never create register moves of hard registers. Because that is incorrect (there may not be insns to do it). It's a separate issue. You're extending Jakub's patch here, not replacing it, so that's fine. > In pr84524.c we got a loop with an extended inline asm: > asm volatile ("" : "+r" (v)) > which also gives us a “surprising” situation Alexander predicts. > > For sched-deps scanner such volatile asm is a “true barrier” and we > create dependencies to almost all other instructions, while DF scanners > don’t give us such information. There is no such thing as a "true barrier" in extended asm. The only thing volatile asm means is that the asm has a side effect unknown to the compiler; this can *not* be a modification of a register or of memory contents, such things are known by the compiler, that's what clobbers and "memory" clobber are about. > Maybe it is a good idea somehow re-implement modulo scheduler using only > one scanner instead of two, but at the moment the best thing to do is to > detect the situation earlier and skip such loops. Or fix the broken code... Segher