From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132]) by sourceware.org (Postfix) with ESMTPS id 1AD693858C98 for ; Thu, 29 Feb 2024 14:28:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1AD693858C98 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1AD693858C98 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::1132 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709216923; cv=none; b=so6kxi0qIsGAI+GNp/E3Purkrxlj4cuLpRNbV8mE2hPtCr1kFexexZAdYyHxqs9n++Z0c0heDhFzEsj/i9oET1lxdLGWETHzyc3eOvIQ/2HdXEZBg6KWMm/WrI01s34DstuIUixOycWpW1DW98T/kBi/9JYNn1CqCq7+UOMQjdE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709216923; c=relaxed/simple; bh=3FpGo1WJ1Ag8pykrfoVBJ4U/F7xr4BrYESnx7dTAXGo=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=vzvxh6jFSNVjf2K76mCkDi5xLSKgTAtrMgDnY9/Al5Ka5hrFhWJAEwgsJnAeqJKzZCsmgsH1BpXcvrnIxkhKGyVj6rolSfRCzqvf+nPWbkllM9Dc6nRDxdBLrCBXRU7/+v/7CTkufNBCCTi3HuiDmy0VCXU4bWZXzpDOIJH3HnE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-607c5679842so10450687b3.2 for ; Thu, 29 Feb 2024 06:28:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709216920; x=1709821720; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=wVQ+xEnXqKB8GcQmpaOMFRk+hP6Hrm6pPs77z5kMaEA=; b=MJ8ZoE1FPDw5hhgWvS7xyBBRDe6/Q++XUjk4TsdyiY+lZyglngOKDR+aFr3bN6SXPA dPRE14mTX12QWRGrpBxvIuZrWJ5qzDyc9AZh5MQHMEjuvEZ7jTudcLSj/DiExYN7BnDk TXAbStKxxFXrLsPLJqgAo9+yjiOIWZFOFHzRsUpc16BsUb8utLSdoyWLZzxOWcScuXJM +BMSNXFhqKQmJvg2ZDXtoZ2HznBsNEm1we/zZZ7BZU3NlBvCtHGV1vjzzVJcO9hZGfhx 9nGR8jMMGZwHAQbZTdG0rxidBOlr+GFvVT6QBLObmpUtr9O05swsBcrM0xLZqJBNRdHQ LSEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709216920; x=1709821720; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wVQ+xEnXqKB8GcQmpaOMFRk+hP6Hrm6pPs77z5kMaEA=; b=J6IYy6ggO/EQzPXwuXs0+TA6wAnPDBqaCk38GzgTqMELRCo5gCDeQQn4MD+MXHcGmC k8zCA2b2FVWKel/bdDOzAFZRauhXvt2uZXylMZYP66edRvt+uGilNKxkI7zZOUyJl8qX 1ScX1th59zD2G7N/w95KTIXGGITNCbDb+zMIL7QB3yQcjyJv0+4fdmd7so7sNG1q7bTF +sY+VYjkNlm188dGHxz3Z82BFiIK+ip+G6+LipzwtLShYm/j0hu9mYPmxcXT6njcq3kp ztIhEDMM0uBkAivLXt9Q95Py7H4EzTrheNd0mxTxiMo3YCicDS27bKZJdlnsU8PNR+H0 njkQ== X-Forwarded-Encrypted: i=1; AJvYcCXPAaAiWluQhj4HpEJAUkcLjJLmG1zOrUIfczvko6DrQWAY6qUxpiKfbaMCNyCAp4WvMZxFLAsYuGsYk7NUDpo+szPlBNMcBg== X-Gm-Message-State: AOJu0Yz1kvO72qB0EWfGUg9iPcCHH8pW+J4CWP79GBwG+IkSL3o1KNZS UsgARZ/9FhoigIow8uJbTEc/TPaL3PsSG3Ha7Noa09+zlknmh57leyV84ZqdiE9SuXKPuE/qyXi 0dXp2+nzZi6nYfgYinkOBK6YcKmo= X-Google-Smtp-Source: AGHT+IEugsAIb/QJYPsTpzgA2s8l9a0dCZkypYnmqDqKpdz2T39hV3sIVzXi1Hfpr5KY6/E9y2xBQihVG1VtGQVazEc= X-Received: by 2002:a05:690c:5:b0:609:4736:b05d with SMTP id bc5-20020a05690c000500b006094736b05dmr2654612ywb.1.1709216920363; Thu, 29 Feb 2024 06:28:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "H.J. Lu" Date: Thu, 29 Feb 2024 06:28:04 -0800 Message-ID: Subject: Re: [PATCH] i386: Guard noreturn no-callee-saved-registers optimization with -mnoreturn-no-callee-saved-registers [PR38534] To: Jan Hubicka Cc: Jakub Jelinek , Richard Biener , Hongtao Liu , Uros Bizjak , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3014.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: On Thu, Feb 29, 2024 at 6:15=E2=80=AFAM Jan Hubicka wrote: > > > On Thu, Feb 29, 2024 at 02:31:05PM +0100, Jan Hubicka wrote: > > > I agree that debugability of user core dumps is important here. > > > > > > I guess an ideal solution would be to change codegen of noreturn func= tions > > > to callee save all registers. Performance of prologue of noreturn > > > function is not too important. THen we can stop caller saving registe= rs > > > and still get reasonable backtraces. > > > > I don't think that is possible. > > While both C and C++ require that if [[noreturn]] attribute is used on > > some function declaration, it must be used on the first declaration and > > also if some function is [[noreturn]] in one TU, it must be [[noreturn]= ] > > in all other TUs which declare the same function. > > But, we have no such requirement for __attribute__((noreturn)), there i= t > > is a pure optimization, it can be declared just on the caller side as a= n > > optimization hint the function will not return, or just on the callee s= ide > > where the compiler will actually verify it doesn't return, or both. > > And, the attribute is not part of function type, so even in standard C/= C++, > > one can use > > extern void bar (); > > [[noreturn]] void foo () > > { > > for (;;) bar (); > > } > > void (*fn) () =3D foo; > > void baz () > > { > > fn (); > > } > > As you can call the noreturn function directly or indirectly, changing > > calling conventions based on noreturn vs. no-noreturn is IMHO not possi= ble. > > I am not wed to the idea (just it appeared to me as an option to > disabling this optimization by default). I still think it may make sense. > > Making noreturn calles to save caller saved register is compatible with > the default ABI. If noreturn is missing on caller side, then caller will > save reigsters as usual. Noreturn callee will save them again, which is > pointless, but everything should work as usual and extra cost of saving > should not matter in practice. This is also the case of indirect call > of noreturn function where you miss annotation on caller side. > > If noreturn is missing on callee side, we will lose information on > functions arguments in backtrace, but the code will still work > (especially if we save BP register to make code backtraceable). This is > scenario that probably can be avoided in practice where it matters (such > as in glibc abort whose implementation is annotated). > > Noreturn already leads to some information loss in backtraces. I tend to > get surprised from time to time to see whrong call to abort due to tail > merging. So it may be acceptable to lose info in a situation where user > does sily thing and only annotates caller. > > Since we auto-detect noreturn, we may need to be extra careful about nore= turn > comdats. Here auto-detection of prevailing def may have different > outcome than auto-detection of prevailed defs. So we may want to disable > the optimization for auto-detected comdats. > There are 2 kinds of noreturns. One is abort which may require backtrace. The other is a normal exit from the previous frame. The latter case doesn'= t require backtrace and can be performance critical. Which one is more important for users? --=20 H.J.