This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 0/9] start converting POINTER_SIZE to a hook
- From: Richard Sandiford <richard dot sandiford at arm dot com>
- To: Trevor Saunders <tbsaunde at tbsaunde dot org>
- Cc: Jeff Law <law at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>, tbsaunde+gcc at tbsaunde dot org, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 29 Jul 2015 09:11:21 +0100
- Subject: Re: [PATCH 0/9] start converting POINTER_SIZE to a hook
- Authentication-results: sourceware.org; auth=none
- References: <1437966615-21093-1-git-send-email-tbsaunde+gcc at tbsaunde dot org> <CAFiYyc0=9XjGrnECPrVC708v=2ryKH_YXqnKP8ri+VpbgPrYtg at mail dot gmail dot com> <55B658F1 dot 10300 at redhat dot com> <87a8uhfjt7 dot fsf at googlemail dot com> <20150728034406 dot GB23293 at tsaunders-iceball dot corp dot tor1 dot mozilla dot com> <873808f2tq dot fsf at googlemail dot com> <20150729000452 dot GA8356 at tsaunders-iceball dot corp dot tor1 dot mozilla dot com>
Trevor Saunders <tbsaunde@tbsaunde.org> writes:
> 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?
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.
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.
Thanks,
Richard