From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95081 invoked by alias); 3 Mar 2018 23:47:58 -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 95069 invoked by uid 89); 3 Mar 2018 23:47:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:c8d532a, H*i:sk:c8d532a 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 23:47:56 +0000 Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w23NkdWl036590 for ; Sat, 3 Mar 2018 18:47:54 -0500 Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by mx0a-001b2d01.pphosted.com with ESMTP id 2gfpwhvjq7-1 (version=TLSv1.2 cipher=AES256-SHA256 bits=256 verify=NOT) for ; Sat, 03 Mar 2018 18:47:53 -0500 Received: from localhost by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sat, 3 Mar 2018 16:47:53 -0700 Received: from b03cxnp07029.gho.boulder.ibm.com (9.17.130.16) by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Sat, 3 Mar 2018 16:47:51 -0700 Received: from b03ledav001.gho.boulder.ibm.com (b03ledav001.gho.boulder.ibm.com [9.17.130.232]) by b03cxnp07029.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w23NlofA9109786; Sat, 3 Mar 2018 16:47:50 -0700 Received: from b03ledav001.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DDD7B6E03A; Sat, 3 Mar 2018 16:47:50 -0700 (MST) Received: from otta.local (unknown [9.80.218.254]) by b03ledav001.gho.boulder.ibm.com (Postfix) with ESMTP id 3955D6E03D; Sat, 3 Mar 2018 16:47:50 -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> <7e2bab00-e9c8-c05f-9a80-239b9620d979@vnet.ibm.com> From: Peter Bergner Date: Sat, 03 Mar 2018 23:47: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: 18030323-0024-0000-0000-000018075891 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008617; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000254; SDB=6.00997965; UDB=6.00507474; IPR=6.00777284; MB=3.00019841; MTD=3.00000008; XFM=3.00000015; UTC=2018-03-03 23:47:52 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18030323-0025-0000-0000-00004EF63F61 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-03-03_13:,, 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-1803030299 X-IsSubscribed: yes X-SW-Source: 2018-03/txt/msg00025.txt.bz2 On 3/3/18 10:29 AM, Jeff Law wrote: > Here's the comment from regstat.c: > > /* We have a problem with any pseudoreg that lives > across the setjmp. ANSI says that if a user variable > does not change in value between the setjmp and the > longjmp, then the longjmp preserves it. This > includes longjmp from a place where the pseudo > appears dead. (In principle, the value still exists > if it is in scope.) If the pseudo goes in a hard > reg, some other value may occupy that hard reg where > this pseudo is dead, thus clobbering the pseudo. > Conclusion: such a pseudo must not go in a hard > reg. */ I can't argue with anything in that comment, other than the conclusion. :-) It's not the compiler's job to implement the setjmp/longjmp save/restore. Maybe Kenny was working around a problem with some target's buggy setjmp and spilling everything "fixed" it? It is absolutely fine for a pseudo that is live across a setjmp call to occupy a (non-volatile) hard register at the setjmp's call site, even if some other value eventually occupies the same hard register between the setjmp and the longjmp. The reason is that setjmp saves all of the non- volatile hard registers in the jmp_buf. If our pseudo was assigned to one of those non-volatile hard registers, then its value at the time of the setjmp call is saved, so even if its hard register is clobbered before we get to the longjmp call, the longjmp will restore the pseudos value from the jmp_buf into the hard register, restoring the value it had at the time of the setjmp call. The only way I can see the above not working is either setjmp doesn't save the entire register state it should, the jmp_buf somehow gets clobbered before the longjmp call or longjmp doesn't restore the entire register state that it should. All of those would be bugs in my book. The only thing the register allocator should need to do, is treat setjmp just like any other function call and make all pseudos that are live across it interfere with all volatile hard registers, so that they will be assigned to either non-volatile hard registers or spilled (if no non-volatile registers are available). Peter