From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 9FBD92D765 for ; Tue, 27 Aug 2024 17:42:51 +0200 (CEST) Received: (qmail 20093 invoked by uid 550); 27 Aug 2024 15:42:47 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 20058 invoked from network); 27 Aug 2024 15:42:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724773358; x=1725378158; darn=lists.openwall.com; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=AG7DjlMHDtZKQjteTjAcNpdS1YbPT8Kh3cVs1qmJGCU=; b=m3uBTTUIuquj58/Mtny0V5NbNnax+dU7CatJ/Sf1MKcq+SQs2WHPlJFaD/0Co7B4GV MY6iB6rkY7VrqBKqhl57GBQM6cqOAVpqD9cLs6yUwwcPCMqiNPcIe3cZIbLaO/zoStrG NnlxEATVjITWdW0ipprhpSVdRWZ1gHzG6rG1j9D/tKSmGSZKqwVlIQhHlouq/i3B+Oss F36Yll6bMhzsaO42NjcPI3P/1Vyp84IXOC1CcQ6jNzDkvQxyCU/9FNT8XkrQHB4W0iF2 6D+NF5dbLglrem+Dx4OjP0xN6JqrYRBUb0prq8nOiv9YJAhHN+KzAMOM+qO/beTWSVVP tpTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724773358; x=1725378158; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=AG7DjlMHDtZKQjteTjAcNpdS1YbPT8Kh3cVs1qmJGCU=; b=aZvdEk57JKDgYGna3aiZoaYehNX/hbbJkbnKxxZPtInrPs/5SNA8XaCN5AhORTv6fE vS8bZKC9f/FwjQ1VQfOOxWyVkkhpZI5IA/KdVeWt+pFUyEqfJiQ9EMPc+dv5l4ywccbL tpEmwKQnRaPqNgbH6GcVDRegLG2SokOD4qvJNZRn4w0FsrRASu9tok60LTgxu/91mnrK Szbj5tZbzJfaTNngLAc/q6mHfnOiCaS+lV7qtICjqqmgCwXAGqSeUJBZdKqHvQUQyW+P +Q+D+mU5yK0YYueFI3uQeCCw7R02QjgRo1z4hH/uLUF8BuXEWP4fhK8WhPzEb2FQtTgc eKfg== X-Gm-Message-State: AOJu0Ywt9AbZZweDxD/inMbISAst33C5NquQPTfvrvLMQ18zqSt4WggI BNkrDMDB8taX2HaYXMf43YVALCeN8gtQwNHPpfayubGEZh/RP5jP4DuPaw== X-Google-Smtp-Source: AGHT+IF9Rq+6ux/YTOhDKX2jqjN26+ffRTM51xbH5lV+/EYIQOffDNKbiyUqYJHLt6/yB9/B5GY/NQ== X-Received: by 2002:adf:fc4b:0:b0:371:8f26:67f1 with SMTP id ffacd0b85a97d-3748c7d522cmr2177164f8f.33.1724773357798; Tue, 27 Aug 2024 08:42:37 -0700 (PDT) Date: Tue, 27 Aug 2024 16:42:35 +0100 From: Pedro Falcato To: Rich Felker Cc: musl@lists.openwall.com Message-ID: References: <20240826200958.GD10433@brightrain.aerifal.cx> <20240827152133.GE10433@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240827152133.GE10433@brightrain.aerifal.cx> Subject: Re: [musl] Proposed printf stack usage improvement On Tue, Aug 27, 2024 at 11:21:33AM GMT, Rich Felker wrote: > On Tue, Aug 27, 2024 at 10:23:57AM +0100, Pedro Falcato wrote: > > LGTM. > > > > But maybe you should also include my __attribute__((noinline)) > > sugestion, to make sure the integer printf and floating point paths > > get mixed by the compiler. Even if current gcc/clang don't seem to > > want to do that, it's better to be safe than sorry (and I assume any > > LTO/PGO might change that atm). > > I'm not clear what ill effect you're trying to mitigate here. (fwiw, if it wasn't clear: I meant "make sure the <...> *don't* get mixed) fmt_fp with the patch applied still has a significant stack impact (520 bytes according to my measurement) which can be avoided on the vast majority of (integer) printfs. printf_core OTOH uses up 472 bytes of stack, so the simple possibility of inlining it can (worst case) more than double the stack space used by all printfs. Granted, the patch seems to convince clang not to inline fmt_fp at all, but AFAIK this is by no means a guarantee. One could consider this somewhat of a microoptimization, but musl thread stacks are by no means big, so... -- Pedro