On Wed, Jul 29, 2015 at 09:11:21AM +0100, Richard Sandiford wrote:
> Trevor Saunders <tbsau...@tbsaunde.org> writes:
> > On Tue, Jul 28, 2015 at 09:24:17PM +0100, Richard Sandiford wrote:
> >> Trevor Saunders <tbsau...@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?
>
> Yeah, but the idea was that the hook would only be called once per
> target initialisation and the result would be stored in a target_globals
> structure. Then places that use POINTER_SIZE would instead use the
> cached target_globals structure rather than targetm.
ok, personally I always found the have global state and update it
appropriately approach a little distasteful, but I have to admitt it
makes getting values faster than anything else, and otherwise works. I
guess if we ever care about threaded compilation for the jit or whatever
that's not true, but that's not a bridge we need to cross now.
> For SWITCHABLE_TARGETs, the hook would be called only once for each
> subtarget used by the TU. For other targets it would be called
> once for each change in subtarget (which is already very expensive without
> SWITCHABLE_TARGET -- targets that want it to be fast should move to
> SWITCHABLE_TARGET).
>
> The disadvantage of:
>
> const target_types &targetm.get_type_data ()
>
> is that it pushes the caching logic into targetm rather than sharing
> it between all ports. This could be a particular problem for targets
> like MIPS that support a lot of variations.
true, though I was expecting for most targets you'd just have a couple
static const structs and just choose which one to return based onthe
subtarget which wouldn't be too bad.
Trev
>
> Thanks,
> Richard
>
