Re: [01/32] Add function_abi.{h,cc}

[Richard Sandiford <richard dot sandiford at arm dot com>]

Hi Jeff,

Thanks as always for the reviews :-)

Jeff Law <law@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.sandiford@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.

> 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.)

Richard