From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47212 invoked by alias); 4 Mar 2018 00:30:48 -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 47200 invoked by uid 89); 4 Mar 2018 00:30:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:f2edc1b, H*f:sk:f2edc1b 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; Sun, 04 Mar 2018 00:30:46 +0000 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w240Sujq086741 for ; Sat, 3 Mar 2018 19:30:44 -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 2gfrp235gw-1 (version=TLSv1.2 cipher=AES256-SHA256 bits=256 verify=NOT) for ; Sat, 03 Mar 2018 19:30:44 -0500 Received: from localhost by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sat, 3 Mar 2018 17:30:43 -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; Sat, 3 Mar 2018 17:30:41 -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 w240UeEj10617202; Sat, 3 Mar 2018 17:30:40 -0700 Received: from b03ledav001.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D7F286E038; Sat, 3 Mar 2018 17:30:40 -0700 (MST) Received: from otta.local (unknown [9.80.218.254]) by b03ledav001.gho.boulder.ibm.com (Postfix) with ESMTP id 285726E03D; Sat, 3 Mar 2018 17:30:40 -0700 (MST) Subject: Re: Why does IRA force all pseudos live across a setjmp call to be spilled? From: Peter Bergner 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> Date: Sun, 04 Mar 2018 00:30: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: 18030400-0012-0000-0000-000015D79754 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.00997980; UDB=6.00507482; IPR=6.00777298; MB=3.00019841; MTD=3.00000008; XFM=3.00000015; UTC=2018-03-04 00:30:43 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18030400-0013-0000-0000-000051BA7475 Message-Id: <3f6c4ed0-faaa-bfe1-3db0-527555572ab0@vnet.ibm.com> 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-1803040005 X-IsSubscribed: yes X-SW-Source: 2018-03/txt/msg00026.txt.bz2 On 3/3/18 5:47 PM, Peter Bergner wrote: > 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? The only observable difference I can see between a variable that has been spilled to memory versus one that is assigned to a non-volatile hard reg is if it is modified between the setjmp and the longjmp. In the case where the variable is spilled to memory, the "new" updated value is the value you _may_ see on the return from setjmp (the return caused by the call to longjmp), whereas if it is assigned to a non-volatile register, then you _will_ see the "old" value that was saved by the setjmp call. I say _may_ see above, because there are cases were we might not store the "new" updated value to memory, even if we've spilled the pseudo. Examples would be spill code optimization, or the variable has been broken into separate live ranges/pseudos. etc. etc. I guess I can even think of cases where we could see both "old" and "new" values of a variable. Think of a variable that has been spilled/split like below: a = [start of live range, a assigned to non-volatile reg] spill store a ... setjmp() ... 1) ... = ... a ... [end of live range] ... [a not assigned to a reg in this region] spill load a [start of live range] 2) ... = ... a ... [end of live range] ... if (...) a = [start of live range] 3) spill store a [end of live range] ... [a not assigned to a reg in this region] longjmp() On return from setjmp (the return caused by the call to longjmp), the use of "a" at "1)" will use the non-volatile hard register that was saved by the initial call to setjmp, so it will see the "old" value of "a". However, since the use of "a" at "2)" loads the value from memory, it will use the "new" value stored by the spill load at "3)"! That said, the comment above only talks about variables that do not change between the setjmp and the longjmp and in that case, you will see the same "old" value (which is the only value, since it wasn't modified) regardless of whether it was spilled or not. What does ANSI (or any spec) say about what should happen to variables that are modified between the setjmp and longjmp calls? Maybe all bets are off, given the example above, since even spilling a variable live across a setjmp can still lead to strange behavior unless you don't allow spill/split optimization and I don't think we'd want that at all. Peter