From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id CFB6C3858C2C for ; Thu, 14 Oct 2021 13:29:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CFB6C3858C2C Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id A151B2197D; Thu, 14 Oct 2021 13:29:55 +0000 (UTC) Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 9AB0DA3B84; Thu, 14 Oct 2021 13:29:55 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id 792F0660D; Thu, 14 Oct 2021 13:29:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id 77BCA65F5; Thu, 14 Oct 2021 13:29:55 +0000 (UTC) Date: Thu, 14 Oct 2021 13:29:55 +0000 (UTC) From: Michael Matz To: Richard Biener cc: gcc-patches@gcc.gnu.org, hubicka@ucw.cz Subject: Re: [PATCH][RFC] Introduce TREE_AOREFWRAP to cache ao_ref in the IL In-Reply-To: Message-ID: References: <3313269o-5444-9142-o8ro-1s59r67083pq@fhfr.qr> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 13:29:58 -0000 Hello, On Thu, 14 Oct 2021, Richard Biener wrote: > > So, at _this_ write-through of the email I think I like the above idea > > best: make ao_ref be a tree (at least its storage, because it currently > > is a one-member-function class), make ao_ref.volatile_p be > > tree_base.volatile_flag (hence TREE_VOLATILE(ao_ref)) (this reduces > > sizeof(ao_ref) by 8), increase all nr-of-operand of each tcc_reference by > > 1, and make TREE_AO_REF(reftree) be "TREE_OPERAND(reftree, > > TREE_CODE_LENGTH(reftree) - 1)", i.e. the last operand of such > > tcc_reference tree. > > Hmm. I'm not sure that's really something I like - it's especially > quite some heavy lifting while at the same time lacking true boldness > as to changing the representation of memory refs ;) Well, it would at least enable such changes later in an orderly fashion. > That said - I've prototyped the TREE_ASM_WRITTEN way now because it's > even simpler than the original TREE_AOREFWRAP approach, see below. > > Note that I'm not embedding it into the tree structure, I'm merely > using the same allocation to store two objects, the outermost ref > and the ao_ref associated with it. Quote: > > + size_t length = tree_code_size (TREE_CODE (lhs)); > + if (!TREE_ASM_WRITTEN (lhs)) > + { > + tree alt_lhs > + = ggc_alloc_cleared_tree_node_stat (length + sizeof (ao_ref)); > + memcpy (alt_lhs, lhs, length); > + TREE_ASM_WRITTEN (alt_lhs) = 1; > + *ref = new ((char *)alt_lhs + length) ao_ref; You need to ensure that alt_lhs+length is properly aligned for ao_ref, but yeah, for a hack that works. If you really want to go that way you need good comments about this hack. It's really somewhat worrisome that the size of the allocation depends on a bit in tree_base. (It's a really cute hack that works as a micro optimization, the question is, do we really need to go there already, are all other less hacky approaches not bringing similar improvements? The cuter the hacks the less often they pay off in the long run of production software :) ) Ciao, Michael.