From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75316 invoked by alias); 29 Jul 2015 00:05:10 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 75306 invoked by uid 89); 29 Jul 2015 00:05:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: paperclip.tbsaunde.org Received: from tbsaunde.org (HELO paperclip.tbsaunde.org) (66.228.47.254) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Jul 2015 00:05:08 +0000 Received: from tsaunders-iceball.corp.tor1.mozilla.com (unknown [66.207.208.102]) by paperclip.tbsaunde.org (Postfix) with ESMTPSA id A8DA6C06B; Wed, 29 Jul 2015 00:05:05 +0000 (UTC) Date: Wed, 29 Jul 2015 04:44:00 -0000 From: Trevor Saunders To: Jeff Law , Richard Biener , tbsaunde+gcc@tbsaunde.org, GCC Patches , rdsandiford@googlemail.com Subject: Re: [PATCH 0/9] start converting POINTER_SIZE to a hook Message-ID: <20150729000452.GA8356@tsaunders-iceball.corp.tor1.mozilla.com> References: <1437966615-21093-1-git-send-email-tbsaunde+gcc@tbsaunde.org> <55B658F1.10300@redhat.com> <87a8uhfjt7.fsf@googlemail.com> <20150728034406.GB23293@tsaunders-iceball.corp.tor1.mozilla.com> <873808f2tq.fsf@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <873808f2tq.fsf@googlemail.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-07/txt/msg02418.txt.bz2 On Tue, Jul 28, 2015 at 09:24:17PM +0100, Richard Sandiford wrote: > Trevor Saunders writes: > > On Mon, Jul 27, 2015 at 09:05:08PM +0100, Richard Sandiford wrote: > >> Alternatively we could have a new target_globals structure that is > >> initialised with the result of calling the hook. If we do that though, > >> it might make sense to consolidate the hooks rather than have one for > >> every value. E.g. having one function for UNITS_PER_WORD, one for > >> POINTER_SIZE, one for Pmode, etc., would lead to some very verbose > >> target code. > > > > so something like > > > > struct target_types > > { > > unsigned long pointer_size; > > ... > > }; > > > > const target_types &targetm.get_type_data () > > > > ? that seems pretty reasonable, and I wouldn't expect too many ordering > > issues, but who knows. Its too bad nobody has taken on the big job of > > turning targetm into a class so we can hope for some devirt help from > > the compiler. > > I was thinking more: > > void targetm.get_type_data (target_types *); > > The caller could then initialise or post-process the defaults. The > target_types would eventually end up in some target_globals structure. but wouldn't that mean the hook would need to initialize all the fields every time the hook was called? I'd think you'd want to avoid that work, and have a global or set of global constant target_types structs, and based on the target in use you could return the appropriate one. a target could also just have global one, but change its values when the sub target changes, but having it be constant seems like a nicer design for the target. I guess that has the disadvantage that if the target isn't a switchable target you need to reinitialize the whole struct every time the hook is called on the off chance something has changed, but that seems like the same thing that happens in your proposal? Trev > > Thanks, > Richard