From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16]) by sourceware.org (Postfix) with ESMTPS id 0C2313858C98 for ; Thu, 29 Feb 2024 13:31:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0C2313858C98 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=ucw.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kam.mff.cuni.cz ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0C2313858C98 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.113.20.16 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709213475; cv=none; b=UJPo0x29a9y2PVOcCKTGZMasTor8/rPj1+jBAqyar7zOGn+mNGXlSEwjCIjcgTo1fs/z13be8Vl809fM83ZPOKGuFSLODdIoSu0QhNd4uZc7FHiYEW02sJBlgCDtuU7kW5aO+Je6V5miXXHyaBWLA0vOc36aw9uSGWK9SPQ9XR0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709213475; c=relaxed/simple; bh=OVx4RoaGXP1U72kFn7P4KD/8kJgSrS1JDudN0xgDLjM=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=E7YQjlq9bNDlmqgDGGU4QVrIa5JzaBLK6wyobgQ+ZfUFomQgii3X6CoCmoGkTx5/ahp1SiRjpJhdwoqJSx2JZSXU5XGFhcvOtlKNLbZWywrvci/I2tHZesohu3MPEeNjkpqrVXJB5GgD6Rn610F/7ou6XTeAgETTsSOVirGjZJU= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id EB8FC2841E2; Thu, 29 Feb 2024 14:31:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucw.cz; s=gen1; t=1709213465; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XsMFwB9vvJCvO1DCBsSa/SAnfLZuW+d2Pe+CgSPV86o=; b=nOdZs0KVckVhG3ZRH6aDCYhr6NmdJLWmrE3F/loCYh5yoofGVHSC1AKJhRIHy/V32+c+sY PEjBEywLaQiIqcuBYdWRSLiNaMflPIcXfdnY2BT5P74Q++b7W7DFJiF4FjxwT0wsph4PkQ pC7gVWJam3B0wDzVcj2Ue4R6vc+dnOw= Date: Thu, 29 Feb 2024 14:31:05 +0100 From: Jan Hubicka To: Richard Biener Cc: Jakub Jelinek , "H.J. Lu" , Hongtao Liu , Uros Bizjak , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] i386: Guard noreturn no-callee-saved-registers optimization with -mnoreturn-no-callee-saved-registers [PR38534] Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,JMQ_SPF_NEUTRAL,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > > > > The problem is that it doesn't help in this case. > > If some optimization makes debugging of some function harder, normally it is > > enough to recompile the translation unit that defines it with -O0/-Og, or > > add optimize attribute on the function. > > While in this case, the optimization interferes with debugging of other > > functions, not necessarily from the same translation unit, not necessarily > > even from the same library or binary, or even from the same package. > > As I tried to explain, supposedly glibc abort is compiled with -O2 and needs > > a lot of registers, so say it uses all of %rbx, %rbp, %r12, %r13, %r14, > > %r15 and this optimization is applied on it. That means debugging of any > > application (-O2, -Og or even -O0 compiled) to understand what went wrong > > and why it aborted will be harder. Including core file analysis. > > Recompiling those apps with -O0/-Og will not help. The only thing that > > would help is to recompile glibc with -O0/-Og. > > Doesn't have to be abort, doesn't have to be glibc. Any library which > > exports some noreturn APIs may be affected. > > And there is not even a workaround other than to recompile with -O0/-Og the > > noreturn functions, no way to disable this optimization. > > > > Given that most users just will not be aware of this, even adding the option > > but defaulting to on would mean a problem for a lot of users. Most of them > > will not know the problem is that some noreturn function 10 frames deep in > > the call stack was optimized this way. > > > > If people only call the noreturn functions from within the same package, > > for some strange reason care about performance of noreturn functions (they > > don't return, so unless you longjmp out of them or something similar > > which is costly on its own already, they should be entered exactly once) > > and are willing to pay the price in worse debugging in that case, let them > > use the option. But if they provide libraries that other packages then > > consume, I'd say it wouldn't be a good idea. > > +1 > > I'll definitely patch this by-default behavior out if we as upstream keep it. > Debugging customer core dumps is more important than optimizing > glibc abort/assert. > > I do hope such patch will be at least easy, like flipping the default of an > option. I agree that debugability of user core dumps is important here. I guess an ideal solution would be to change codegen of noreturn functions to callee save all registers. Performance of prologue of noreturn function is not too important. THen we can stop caller saving registers and still get reasonable backtraces. This is essentially an ABI change (though kind of conservative one since nothing except debugging really depends on it). Perhaps it would make sense to make the optimization non-default option now and also implement the callee save logic. Then we should be able to flip release or two later. Maybe synchroniation with LLVM would be desirable here if we decide to go this route. Honza > > Richard. > > > Jakub > >