Re: -fuse-caller-save - Collect register usage information

[Tom de Vries <Tom_deVries at mentor dot com>]

On 17-10-14 21:24, Eric Botcazou wrote:
> > Let's look at the effect of the option (after the recent fix for PR61605) on
> > gcc.target/i386/fuse-calller-save.c:
> > ...
> >    foo:
> >    .LFB1:
> >    	.cfi_startproc
> > -	pushq	%rbx
> > -	.cfi_def_cfa_offset 16
> > -	.cfi_offset 3, -16
> > -	movl	%edi, %ebx
> >    	call	bar
> > -	addl	%ebx, %eax
> > -	popq	%rbx
> > -	.cfi_def_cfa_offset 8
> > +	addl	%edi, %eax
> >    	ret
> >    	.cfi_endproc
> >    .LFE1:
> > ...
> > So, the effect is: instead of using a callee-save register, we use a
> > caller-save register to store a value that's live over a call, without
> > needing to add a caller-save, as would be normally the case.
> >
> > If I see an option -foptimize-caller-saves, I'd expect the effect to be that
> > without, there are some caller-saves and with, there are less. This is not
> > the case in the diff above.
>
> To me it is, "movl %edi, %ebx"/"addl %ebx, %eax" is a caller-save/restore.

I agree that it can look like that. But the insn 'movl %edi, %ebx' is generated 
by assign_parm_setup_reg at expand. AFAIU, the purpose is to decouple the value 
of the argument and its uses from the register it's passed in.

The definition of -fcaller-saves below explains why insn 'movl %edi, %ebx' is 
not a caller-save: because it's not generated before a call, but rather at the 
start of a function. This seems to be confirmed by the fact that the insn 'movl 
%edi, %ebx' is still generated with -fno-caller-saves.

> > I'm starting to lean towards -foptimize-call-clobbers or similar.
>
> Yes, that's also a good name and was my initial preference.  But you pointed
> out the existing -fcaller-saves:
>
> `-fcaller-saves'
>       Enable allocation of values to registers that are clobbered by
>       function calls, by emitting extra instructions to save and restore
>       the registers around such calls.  Such allocation is done only
>       when it seems to result in better code.
>
> so -foptimize-caller-saves can be understood as optimizing out the "extra
> instructions to save and restore  the registers around such calls"  and, thus,
> as having a direct relationship with -fcaller-saves.

Agree.

But, given the preference of a number of others for fipa-ra, could you live with 
that?

Thanks,
- Tom