-fuse-caller-save - Collect register usage information

[Tom de Vries]

On 16-10-14 23:46, Eric Botcazou wrote:
>> Having said that, in my mind, what is confusing about the name
>> -fuse-caller-save, is that in fact the caller-save registers are already
>> used in register allocation. It's just that they're used across calls
>> without the need to save them, but
>> -fuse-caller-save-across-calls-without-saving-if-possible is not such a
>> good option name.
>
> Agreed.
>
>> Another thing that - in my mind - is confusing is that there's an option
>> fcaller-saves which controls behaviour for caller-save registers:
>> - for -fno-caller-saves, caller-save registers are not used across calls
>> - for -fcaller-saves, caller-save registers are used across calls
>> The name is similar to -fuse-caller-save, and it won't be clear from just
>> the names what the difference is.
>
> OK, so the existing -fcaller-saves is in fact -fuse-caller-saves,

Right, in the sense that a caller-save is the save of caller-save register, as 
opposed to short for a caller-save register, which is how it's used in 
-fuse-caller-save.

> which means
> that we should really find a better name for yours. :-)
>

Agreed :)

>> I've pondered the name -fipa-ira, but I rejected that earlier because that
>> might suggest actual register allocation at the interprocedural scope,
>> while this is only register allocation at the scope of a single procedure,
>> taking some interprocedural information into account. Furthermore, it's not
>> only ira that uses the interprocedural information.
>>
>> So, let's a generate a list of option names.
>> -fuse-caller-save
>> -fuse-call-clobbered
>> -fprecise-call-clobbers
>> -foptimize-call-clobbers
>> -fprune-call-clobbers
>> -freduce-call-clobbers
>> -fcall-clobbers-ipa
>>
>> Any preferences, alternatives?
>
> Given the existing -fcaller-saves, I'd keep "caller-saves" in the name, so
> something along the lines of -foptimize-caller-saves or -fipa-caller-saves.
>

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. Nevertheless, if we'd have a case where we already have 
caller-saves, that would be indeed the observed effect. I'm just trying to point 
out that the optimization does more than just removing caller-saves.

The optimization, at it's core, can be regarded as removing superfluous clobbers 
from calls, and everything else is derived from that:
- if a caller-save register is not clobbered by a call, then there's no need
   for a caller-save before that call, so it's cheaper to use across that call
   than a callee-save register.
   (which explains what we see in the diff)
- if a caller-save register is live across a call, and is not clobbered by a
   call, then there's no need for a caller-save, and it can be removed.
   (which explains what we see in case we have an example where there are
    actual caller-saves without the optimization, and less so with the
    optimization)

I'm starting to lean towards -foptimize-call-clobbers or similar.

Thanks,
- Tom