From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=+Ykr=AL=bitrange.com=hp@sourceware.org>
Received: from arjuna.pair.com (arjuna.pair.com [209.68.5.131])
	by sourceware.org (Postfix) with ESMTPS id 4AC263858D33
	for <gcc-patches@gcc.gnu.org>; Thu, 20 Apr 2023 05:37:57 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4AC263858D33
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=bitrange.com
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=bitrange.com
Received: by arjuna.pair.com (Postfix, from userid 3006)
	id 985BB8A71D; Thu, 20 Apr 2023 01:37:56 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by arjuna.pair.com (Postfix) with ESMTP id 977648A701;
	Thu, 20 Apr 2023 01:37:56 -0400 (EDT)
Date: Thu, 20 Apr 2023 01:37:56 -0400 (EDT)
From: Hans-Peter Nilsson <hp@bitrange.com>
X-X-Sender: hp@arjuna.pair.com
To: Richard Biener <rguenther@suse.de>
cc: Richard Sandiford <richard.sandiford@arm.com>, 
    =?UTF-8?B?6ZKf5bGF5ZOy?= <juzhe.zhong@rivai.ai>, 
    "kito.cheng" <kito.cheng@gmail.com>, Jeff Law <jeffreyalaw@gmail.com>, 
    gcc-patches <gcc-patches@gcc.gnu.org>, palmer <palmer@dabbelt.com>, 
    jakub <jakub@redhat.com>
Subject: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to
 16-bit
In-Reply-To: <nycvar.YFH.7.77.849.2304170636010.4466@jbgna.fhfr.qr>
Message-ID: <alpine.BSF.2.20.16.2304200128160.46222@arjuna.pair.com>
References: <20230410144808.324346-1-juzhe.zhong@rivai.ai> <89f088ec-8692-01f5-0395-5a66ddf085d7@gmail.com> <47D962C7C724E3A2+20230410231445834316202@rivai.ai> <mpto7nulpji.fsf@arm.com> <nycvar.YFH.7.77.849.2304111054120.4466@jbgna.fhfr.qr> <mptv8i2k714.fsf@arm.com>
 <0AEFD2378C3DF89B+202304111919556577872@rivai.ai> <CA+yXCZCUcChS_GbuHETPy6R3rgJAAMRHGz1LXYcwnoS-EOFXZg@mail.gmail.com> <nycvar.YFH.7.77.849.2304120743360.4466@jbgna.fhfr.qr> <CA+yXCZCVd3c3c6KWf_t5x714T0brKu7Swh3AXXy+Z3PQ+1Y02A@mail.gmail.com>
 <nycvar.YFH.7.77.849.2304120920111.4466@jbgna.fhfr.qr> <CA+yXCZDa20XPMMLJH9R1XJJ1q+qTN5zrJXWFo=55=UvDw9ubJw@mail.gmail.com> <2978624D57874251+2023041307225185723242@rivai.ai> <mptedoogccu.fsf@arm.com> <nycvar.YFH.7.77.849.2304131401410.4466@jbgna.fhfr.qr>
 <alpine.BSF.2.20.16.2304142234060.23164@arjuna.pair.com> <nycvar.YFH.7.77.849.2304170636010.4466@jbgna.fhfr.qr>
User-Agent: Alpine 2.20.16 (BSF 172 2016-09-29)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Scanned-By: mailmunge 3.11 on 209.68.5.131
X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,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: <gcc-patches.gcc.gnu.org>

On Mon, 17 Apr 2023, Richard Biener wrote:
> On Fri, 14 Apr 2023, Hans-Peter Nilsson wrote:
> > If after all, a change to the size of the code and mode 
> > bit-fields in rtx_def is necessary, like to still fit 64 bytes 

(Sorry: 64 bits, not counting the union u.)

> > such become non-byte sizes *and* that matters for compilation 
> > time, can that change please be made target-dependent?  Not as 
> > in set by a target macro, but rather deduced from the number of 
> > modes defined by the target?
> > 
> > After all, that number is readily available (or if there's an 
> > order problem seems likely to easily be made available to the 
> > rtx_def build-time definition (as opposed to a gen-* -time 
> > definition).
> 
> But it gets us in the "wrong" direction with the goal of having
> pluggable targets (aka a multi-target compiler)?

But also away from the slippery slope of slowing down gcc 
compilation (building and running) while not adding any 
observable value.

(Also, a unified gcc would be years in the future, and the 
proposal is easily removed.)

> Anyway, I suggest we'll see how the space requirements work out.
> We should definitely try hard to put the fields on a byte
> boundary so accesses become at most a load + and.

I'll be quiet until then. :)

brgds, H-P