From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=sttm=4V=ispras.ru=amonakov@sourceware.org>
Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84])
	by sourceware.org (Postfix) with ESMTPS id 7E1093858D1E
	for <gcc-patches@gcc.gnu.org>; Fri, 23 Dec 2022 07:33:41 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7E1093858D1E
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=ispras.ru
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ispras.ru
Received: from [10.10.3.121] (unknown [10.10.3.121])
	by mail.ispras.ru (Postfix) with ESMTPS id 1B6CC419E9DB;
	Fri, 23 Dec 2022 07:33:39 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 1B6CC419E9DB
Date: Fri, 23 Dec 2022 10:33:39 +0300 (MSK)
From: Alexander Monakov <amonakov@ispras.ru>
To: Qing Zhao <qing.zhao@oracle.com>
cc: Jose Marchesi <jose.marchesi@oracle.com>, 
    "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH V2] Disable sched1 in functions that call setjmp
In-Reply-To: <35CA4F79-CA10-4560-8920-CDA65810E308@oracle.com>
Message-ID: <cf62c3ec-0a9e-275e-5efa-2689ff1f00e2@ispras.ru>
References: <20221222173208.13317-1-jose.marchesi@oracle.com> <53b93d7e-a157-9116-d07a-4d51cd43d205@ispras.ru> <35CA4F79-CA10-4560-8920-CDA65810E308@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <gcc-patches.gcc.gnu.org>


On Thu, 22 Dec 2022, Qing Zhao wrote:

> > I think scheduling across calls in the pre-RA scheduler is simply an oversight,
> > we do not look at dataflow information and with 50% chance risk extending
> > lifetime of a pseudoregister across a call, causing higher register pressure at
> > the point of the call, and potentially an extra spill.
> 
> I am a little confused, you mean pre-RA scheduler does not look at the data flow
>  information at all when scheduling insns across calls currently?

I think it does not inspect liveness info, and may extend lifetime of a pseudo
across a call, transforming
 
  call foo
  reg = 1
  ...
  use reg

to

  reg = 1
  call foo
  ...
  use reg

but this is undesirable, because now register allocation cannot select a
call-clobbered register for 'reg'.

Alexander