From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128023 invoked by alias); 3 Mar 2018 03:28:38 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 127994 invoked by uid 89); 3 Mar 2018 03:28:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:f693521, H*i:sk:f693521 X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 03 Mar 2018 03:28:31 +0000 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w233QZqb076474 for ; Fri, 2 Mar 2018 22:28:29 -0500 Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by mx0a-001b2d01.pphosted.com with ESMTP id 2gfdmajfvm-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 02 Mar 2018 22:28:29 -0500 Received: from localhost by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 2 Mar 2018 20:28:28 -0700 Received: from b03cxnp08026.gho.boulder.ibm.com (9.17.130.18) by e35.co.us.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 2 Mar 2018 20:28:26 -0700 Received: from b03ledav001.gho.boulder.ibm.com (b03ledav001.gho.boulder.ibm.com [9.17.130.232]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w233SQpA10158416; Fri, 2 Mar 2018 20:28:26 -0700 Received: from b03ledav001.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0BA976E03A; Fri, 2 Mar 2018 20:28:26 -0700 (MST) Received: from otta.local (unknown [9.80.218.254]) by b03ledav001.gho.boulder.ibm.com (Postfix) with ESMTP id 5A3236E038; Fri, 2 Mar 2018 20:28:25 -0700 (MST) Subject: Re: Why does IRA force all pseudos live across a setjmp call to be spilled? To: Jeff Law Cc: GCC , Vladimir N Makarov , Pat Haugen References: <141cfa78-f202-029a-e530-24e657692bff@vnet.ibm.com> From: Peter Bergner Date: Sat, 03 Mar 2018 03:28:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 18030303-0012-0000-0000-000015D6F63D X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008612; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000254; SDB=6.00997559; UDB=6.00507244; IPR=6.00776878; MB=3.00019828; MTD=3.00000008; XFM=3.00000015; UTC=2018-03-03 03:28:28 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18030303-0013-0000-0000-000051B80F31 Message-Id: <7e2bab00-e9c8-c05f-9a80-239b9620d979@vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-03-03_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1803030038 X-IsSubscribed: yes X-SW-Source: 2018-03/txt/msg00019.txt.bz2 On 3/2/18 3:26 PM, Jeff Law wrote: > On 03/02/2018 12:45 PM, Peter Bergner wrote: >> ...which forces us to spill everything live across the setjmp by forcing >> the pseudos to interfere all hardregs. That can't be good for performance. >> What am I missing? > > You might want to hold off a bit. I've got changes for 21161 which can > help this significantly. Basically the live-across-setjmp set is way > too conservative -- it includes everything live at the setjmp, but it > really just needs what's live on the longjump path. > > As for why, I believe it's related to trying to make sure everything has > the right values if we perform a longjmp. I can understand why we might save/restore across functions that can throw exceptions since the program state hasn't been saved at the point of the call or in the call, but what is special about setjmp()? We don't need to save/restore the volatile regs since all functions clobber them and the non-volatile regs are saved/restored by setjmp(), just like any normal function call. ...and as far as I know, setjmp() doesn't save or restore the stack contents, just the stack pointer, pc, etc. So I guess I still don't know why we treat it differently than any other function call wrt register allocation. Peter