public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Trevor Saunders <tbsaunde@tbsaunde.org>
To: Jeff Law <law@redhat.com>,
	Richard Biener <richard.guenther@gmail.com>,
	tbsaunde+gcc@tbsaunde.org, GCC Patches <gcc-patches@gcc.gnu.org>,
	rdsandiford@googlemail.com
Subject: Re: [PATCH 0/9] start converting POINTER_SIZE to a hook
Date: Wed, 29 Jul 2015 04:44:00 -0000	[thread overview]
Message-ID: <20150729000452.GA8356@tsaunders-iceball.corp.tor1.mozilla.com> (raw)
In-Reply-To: <873808f2tq.fsf@googlemail.com>

On Tue, Jul 28, 2015 at 09:24:17PM +0100, Richard Sandiford wrote:
> Trevor Saunders <tbsaunde@tbsaunde.org> 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

  reply	other threads:[~2015-07-29  0:05 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-27  3:10 tbsaunde+gcc
2015-07-27  3:10 ` [PATCH 9/9] emit-rtl.c: switch to targetm.pointer_size () tbsaunde+gcc
2015-07-27  3:10 ` [PATCH 7/9] stor-layout.c: " tbsaunde+gcc
2015-07-27  3:10 ` [PATCH 2/9] add pointer_size target hook tbsaunde+gcc
2015-07-27  3:10 ` [PATCH 5/9] ubsan.c: switch from POINTER_SIZE to targetm.pointer_size () tbsaunde+gcc
2015-07-27  3:10 ` [PATCH 3/9] target.h: change to use targetm.pointer_size instead of POINTER_SIZE tbsaunde+gcc
2015-07-27  3:10 ` [PATCH 4/9] varasm.c: switch from POINTER_SIZE to targetm.pointer_size () tbsaunde+gcc
2015-07-27  9:32   ` Richard Biener
2015-07-27  3:10 ` [PATCH 1/9] remove POINTER_SIZE_UNITS macro tbsaunde+gcc
2015-07-27  3:42 ` [PATCH 6/9] tree-chkp.c: switch to targetm.pointer_size () tbsaunde+gcc
2015-07-27  3:49 ` [PATCH 8/9] tree.c: " tbsaunde+gcc
2015-07-27  9:26 ` [PATCH 0/9] start converting POINTER_SIZE to a hook Richard Biener
2015-07-27 16:20   ` Jeff Law
2015-07-27 20:15     ` Richard Sandiford
2015-07-28  5:52       ` Trevor Saunders
2015-07-28 20:36         ` Richard Sandiford
2015-07-29  4:44           ` Trevor Saunders [this message]
2015-07-29  8:32             ` Richard Sandiford
2015-07-30  8:13               ` Trevor Saunders
2015-07-30 22:30                 ` Richard Sandiford
2015-07-28  3:47     ` Trevor Saunders
2015-07-29 10:40 ` Richard Earnshaw
2015-07-30  4:55   ` Segher Boessenkool
2015-07-30 13:42 David Edelsohn
2015-07-30 22:26 ` Richard Sandiford

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150729000452.GA8356@tsaunders-iceball.corp.tor1.mozilla.com \
    --to=tbsaunde@tbsaunde.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=law@redhat.com \
    --cc=rdsandiford@googlemail.com \
    --cc=richard.guenther@gmail.com \
    --cc=tbsaunde+gcc@tbsaunde.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).