On 9/30/19 3:19 AM, Richard Sandiford wrote:
> Hi Jeff,
>
> Thanks as always for the reviews :-)
>
> Jeff Law <l...@redhat.com> writes:
>> On 9/11/19 1:03 PM, Richard Sandiford wrote:
>>> This patch adds new structures and functions for handling
>>> multiple ABIs in a translation unit. The structures are:
>>>
>>> - predefined_function_abi: describes a static, predefined ABI
>>> - function_abi: describes either a predefined ABI or a local
>>> variant of one (e.g. taking -fipa-ra into account)
>>>
>>> The patch adds functions for getting the ABI from a given type
>>> or decl; a later patch will also add a function for getting the
>>> ABI of the target of a call insn.
>>>
>>> Although ABIs are about much more than call-clobber/saved choices,
>>> I wanted to keep the name general in case we add more ABI-related
>>> information in future.
>>>
>>>
>>> 2019-09-11 Richard Sandiford <richard.sandif...@arm.com>
>>>
>>> gcc/
>>> * Makefile.in (OBJS): Add function-abi.o.
>>> (GTFILES): Add function-abi.h.
>>> * function-abi.cc: New file.
>>> * function-abi.h: Likewise.
>>> * emit-rtl.h (rtl_data::abi): New field.
>>> * function.c: Include function-abi.h.
>>> (prepare_function_start): Initialize crtl->abi.
>>> * read-rtl-function.c: Include regs.h and function-abi.h.
>>> (read_rtl_function_body): Initialize crtl->abi.
>>> (read_rtl_function_body_from_file_range): Likewise.
>>> * reginfo.c: Include function-abi.h.
>>> (init_reg_sets_1): Initialize default_function_abi.
>>> (globalize_reg): Call add_full_reg_clobber for each predefined ABI
>>> when making a register global.
>>> * target-globals.h (this_target_function_abi_info): Declare.
>>> (target_globals::function_abi_info): New field.
>>> (restore_target_globals): Copy it.
>>> * target-globals.c: Include function-abi.h.
>>> (default_target_globals): Initialize the function_abi_info field.
>>> (target_globals): Allocate it.
>>> (save_target_globals): Free it.
>> So no problem with this as-is. Questions though:
>>
>> 1. Do we need to stream this information for LTO?
>
> At the moment this is all derived information rather than something we need
> to stream directly. E.g. the set of available predefined_function_abis
> really only depends on command-line flags. The mapping from functions
> to predefined_function_abis currently depends only on the function type,
> so streaming the type is enough to recover the ABI too. function_abi
> additionally depends on RTL stuff that doesn't affect LTO.
OK. THanks for clarifying.
>
>> 2. Do we need to support it for the RTL front-end, even if primarily for
>> testing purposes?
>
> Yeah, I guess it could be useful to be able to pretend that a function
> is defined locally with a certain -fipa-ra clobber set, but I think in
> most cases it'd be possible to do this using:
>
> void __attribute__ ((noinline, noclone))
> callee (void)
> {
> asm ("" ::: ...regs...);
> }
>
> (That's the kind of test I've used in the support for the SVE PCS FWIW,
> not posted yet.)
Your call on whether or not it's worth it. Given that it's supposed to
be derived info, I won't lose any sleep if it's not available in the RTL
front-end.
jeff
