From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id CF9343858D39 for ; Mon, 19 Sep 2022 09:16:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CF9343858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663578979; h=from:from:reply-to: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=+76EVChi+ZaUidvRShc6jG4/TpmopxlvPnJchrnqqdY=; b=erjLQAE5bOpOJVrWDi1S8ra7x1KRU1kACK7rniiYD52w2KKq6IM9rAI6Jm6hGby5l2gVQ0 IbmJd/yUIuEKxdW1/5xW/W6Xik0ew8NrvN5LbkcYDYi1hBl+OTQiLv0f5ClmJpRzT3QLTJ cUiIjTuXXc9iyLJUTPRoV5FjXbuozBI= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-49-TT0FdON2M4uf9SmGgEuIBw-1; Mon, 19 Sep 2022 05:16:16 -0400 X-MC-Unique: TT0FdON2M4uf9SmGgEuIBw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 14BF63C138B5; Mon, 19 Sep 2022 09:16:16 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.194]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C26AB2086F60; Mon, 19 Sep 2022 09:16:15 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 28J9GCdE641697 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Sep 2022 11:16:13 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 28J9GCIg641696; Mon, 19 Sep 2022 11:16:12 +0200 Date: Mon, 19 Sep 2022 11:16:11 +0200 From: Jakub Jelinek To: Richard Biener Cc: Florian Weimer , Jason Merrill , Michael Matz , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] libgcc: Decrease size of _Unwind_FrameState and even more size of cleared area in uw_frame_state_for Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP 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 Mon, Sep 19, 2022 at 10:57:25AM +0200, Richard Biener wrote: > For even more uglification and avoiding of the cache effect mentioned below > we could squeeze the 4 bits into the union members, at least on 64bit platforms > (probably not on 32bit ones) ... Maybe, but it would limit the offsets we can represent at least: The union is union { _Unwind_Word reg; _Unwind_Sword offset; const unsigned char *exp; } loc; I guess reg is always pretty small (< 153 or so on most targets), so we could squeeze the 4 bits in there, offset would need to be multiplied by 16 because we can't rely on all offsets being multiples of 16, and exp could be through performing aligned allocations for the expression. That said, while it could save a few bytes and the cache effects, on the other side, we'd need to clear more bytes. On x86_64 the size would be 240 bytes instead of 264 bytes, but we'd need to clear those 240 bytes instead of 120 (ok, unless we want to store just the bytes containing the 4 bits but then it would be even more stores). Jakub