Re: Patch for -mcaller-super-interworking & stack arguments

[Richard Sandiford <rsandifo at redhat dot com>]

Richard Earnshaw <rearnsha@gcc.gnu.org> writes:
> On Wed, 2004-09-01 at 15:14, Richard Sandiford wrote:
>> 	* config/arm/arm.h (CONDITIONAL_REGISTER_USAGE): Make r11 fixed and
>> 	global for -mcaller-super-interworking.
>> 	(CALLER_INTERWORKING_SLOT_SIZE): New macro.
>> 	* config/arm/arm.c (thumb_compute_save_reg_mask): Save r11 if
>> 	CALLER_INTERWORKING_SLOT_SIZE is nonzero and the function does
>> 	not need a frame pointer.
>> 	(arm_get_frame_offsets): Add CALLER_INTERWORKING_SLOT_SIZE bytes to
>> 	the soft frame pointer offset.
>> 	(thumb_expand_prologue): Set up r11 for -mcaller-super-interworking.
>> 	* config/arm/arm.md (*call_reg_thumb, *call_value_reg_thumb): Use
>> 	_interwork_{r7,r11}_call_via_rN if some arguments are passed on
>> 	the stack.  Use frame_pointer_needed to choose between them.
>> 	* config/arm/lib1funcs.asm (_arm_return_{r7,r11}): New functions.
>> 	(interwork_with_frame): New macro.
>> 	(interwork): Add _interwork_{r7,r11}_call_via_rN().
>
> Having thought about this for a while, I now think this is probably the
> best solution.

Thanks.  Installed with your suggested change after retesting on arm-elf
(same test pattern, 'arm-sim{,-mthumb,-mthumb/-mcaller-super-interworking}').

Richard

> However, can you make the following change before
> committing?
>
>> *************** #define STACK_GROWS_DOWNWARD  1
>> *** 1517,1522 ****
>> --- 1523,1542 ----
>>      goes at a more negative offset in the frame.  */
>>   #define FRAME_GROWS_DOWNWARD 1
>>   
>> + /* The amount of scratch space needed by _interwork_{r7,r11}_call_via_rN().
>> +    When present, it is one word in size, and sits at the top of the frame,
>> +    between the soft frame pointer and either r7 or r11.
>> + 
>> +    We only need _interwork_rM_call_via_rN() for -mcaller-super-interworking,
>> +    and only then if some outgoing arguments are passed on the stack.  It would
>> +    be tempting to also check whether the stack arguments are passed by indirect
>> +    calls, but there seems to be no reason in principle why a post-reload pass
>> +    couldn't convert a direct call into an indirect one.  */
>> + #define CALLER_INTERWORKING_SLOT_SIZE			\
>> +   (!TARGET_CALLER_INTERWORKING ? 0			\
>> +    : current_function_outgoing_args_size == 0 ? 0	\
>> +    : UNITS_PER_WORD)
>> + 
>>   /* Offset within stack frame to start allocating local variables at.
>>      If FRAME_GROWS_DOWNWARD, this is the offset to the END of the
>>      first local allocated.  Otherwise, it is the offset to the BEGINNING
>
> This would be clearer if expressed as
>
>  ((TARGET_CALLER_INTERWORKING
>    && current_funciton_outgoing_args_size != 0)
>   ? UNITS_PER_WORD : 0)