Re: [Patch] MIPS: Supply correct call clobbered information for global pointer.

[Richard Sandiford <rdsandiford at googlemail dot com>]

David Daney <ddaney@avtrex.com> writes:
> Richard Sandiford wrote:
>> David Daney <ddaney@avtrex.com> writes:
>>> One thing that concerns me is that it feels like we are lying to 
>>> data-flow.  In df-scan.c (df_get_exit_block_use_set) 
>>> PIC_OFFSET_TABLE_REG_CALL_CLOBBERED is used to check if $gp is used in 
>>> the exit block, which it is not in TARGET_OLDABI.
>> 
>> Well, from a dataflow perspective, marking _all_ registers as used
>> is the conservatively-correct choice.  Marking individual registers
>> as unused is an optimisation.
>> 
>
> But that is the whole point. DCE is optimizing away dead code.

(Right, we agree on that.  For the record, this was part of the
longer "I don't think it's fair to say we're 'lying'" claim.)

> That we 
> have to say that an insn (return) is clobbering $gp when in fact that it 
> doesn't touch $gp just to trick dataflow to treat it as not used doesn't 
> seem 'right'.

But saying "the current value of X is not live after this point" is a
long-established use of (clobber X).  I don't really see it as either
"lying" or "a trick".

>> Also, again from a dataflow perspective, a use of an undefined value is
>> equivalent to no use at all.  (This is why I'm worried about marking
>> the register as call-clobbered at times when we still require it to
>> be treated as call-saved.  Any use of the $gp register after an unsplit
>> call would look like an uninitialised use.)
>> 
>> So I think "lying" is too strong; I think we're actually modelling
>> things accurately.
>> 
>> I did wonder about splitting PIC_OFFSET_TABLE_REG_CALL_CLOBBERED into two,
>> but I thought that might be controversial.  Also, having all the clobbers
>> explicit in RTL seemed slightly neater than having only some of them
>> explicit.
>> 
>> However, if the consensus is that we should split the macro, or maybe
>> introduce a target hook that can add and remove registers from the
>> used-at-end set (a la live_on_entry) then I'd be happy with that too.
>> 
>
> Really I don't have strong feelings about this.  But as long as it is up 
> for discussion, it seems that splitting 
> PIC_OFFSET_TABLE_REG_CALL_CLOBBERED would allow us to model what we are 
> doing in the mips backend.  [...]

Understood.  TBH, of the two, I prefer the target hook.  I think this
is a more general concept: there might be some hard registers that are
call-clobbered at the ABI level, but that are preserved across call
patterns unless the patterns say otherwise.  The PIC register might
be the only one of the standard registers that is likely to be
modelled this way, but some ports could do the same for
target-specific registers.

> [...] To me, the other solutions feel like they 
> are papering over mis-information we are emitting.

OK.  I think we'll have to agree to disagree on that.  I still think
the clobber patch is using established interfaces to provide accurate
info.  The question IMO is whether a new interface would be better.

I left things for a while in the hope that someone with authority
to approve one of the other two approaches would have spoken up.
No-one did, so I went ahead and applied the patch, but taking
advantage of the new emit_clobber function.  It'd be easy to
back out if we do decide to go for one of the other approaches
later.

Richard