Re: Emit more REG_EQUIV notes for function args (PR42235)

[Jeff Law <law@redhat.com>]

On 07/14/10 05:14, Bernd Schmidt wrote:
> When moving arguments into pseudos, we are being very careful not to
> emit any instructions that could possibly clobber other argument
> registers.  Currently, we generate unnecessarily complicated sequences
> of code for simple zero or sign extensions.
>
> With this patch, we check can_extend_p and the necessary predicates to
> see if an extend insn is available for the conversion we have to do.
Right, but what guarantee do we have that the conversion insn doesn't 
clobber a function argument register?   ISTM that to be safe you 
actually have to scan the insns created by gen_extend_insn to ensure 
they don't clobber something important.

I'm not an expert on what ports do these days, but I did work on a port 
(mn10200) where conversion "insns" where implemented as special function 
calls under the hood.  I don't recall if we allowed those special 
function calls to have visible side effects, but if they did, they'd 
show up as clobbers/uses attached to the normal conversion insn.    Of 
course the mn102 is dead, but I think it's method for implementing 
conversions was valid and if another port were to do something similar 
it would likely not interact well with your change.


>   If
> so, we emit the insn directly, and create a REG_EQUIV note of the form
> (sign_extend (mem)).
Creating more REG_EQUIVs seems like a good idea to me.



>    Reload can't really do anything with these yet,
> but there's an optimization in the register allocator to move argument
> loads directly before their use if there's only one use.  On Thumb-2
> this happens already, we seem to generate better code than before.
> Unfortunately Thumb-1, which the PR is about, has some other problems
> which I'll try to fix later.
>    
In theory, given the REG_EQUIV note we ought to get an entry in 
reg_equiv_mem, which the code I'm working on knows it can use instead of 
shoving the pseudo into a stack slot.  Effectively, my code will 
rematerialize the argument from the equivalent memory location 
regardless of the number of uses.


Jeff