Trevor Saunders <tbsau...@tbsaunde.org> writes:
> 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.
Yeah, and targetm isn't really any less global than the target_globals.
(The targetm fields aren't fixed.)
If we make GCC thread-safe or multi-target, I assume/hope we'd apply the
same approach to both targetm and the target_globals data.
Thanks,
Richard
