Re: rs6000 stack_tie mishap again

[Richard Henderson <rth@redhat.com>]

On 03/23/2016 09:10 PM, Alan Modra wrote:
> On Wed, Mar 23, 2016 at 05:04:39PM +0100, Olivier Hainque wrote:
>> The reason why 894 is not accounted in the base ref computation is because it
>> is part of the epilogue sequence, and init_alias_analysis has:
>>
>>        /* Walk the insns adding values to the new_reg_base_value array.  */
>>        for (i = 0; i < rpo_cnt; i++)
>> 	{ ...
>> 		  if (could_be_prologue_epilogue
>> 		      && prologue_epilogue_contains (insn))
>> 		    continue;
>>
>> The motivation for this is unclear to me.
>
> https://gcc.gnu.org/ml/gcc-patches/1999-08n/msg00048.html
>
>> My rough understanding is that we probably really care about frame_related
>> insns only here, at least on targets where the flag is supposed to be set
>> accurately.
>
> Also, possibly just prologue insns.  So you might be able to modify
> init_alias_analysis just to ignore the prologue and skip any need for
> yet another hook.
>
> Let's see what rth thinks.  He did say the patch might need to be
> redone.  :)
> https://gcc.gnu.org/ml/gcc-patches/1999-08n/msg00072.html

I be surprised if this is works as expected without side-effects.  You've now 
exposed the restore of the frame pointer to alias analysis, and it's probably 
not seen as constant anymore.  As you reference, I expect that any patch that 
opens the epilogue to such scrutiny is going to have to special-case the frame 
pointer as well.

That said, as Segher points out later in the thread, one can arrange for hard 
regs within the body to bleed into temporaries used within the epilogue, which 
is bad.  So perhaps this is exactly what's needed longer-term.  More 
investigation is required.

But I expect for stage4, the best solution is to strengthen the stack_tie 
pattern to block all memory.  Early scheduling of the stack frame deallocation 
(a simple logic insn) can't really be that important to performance.


r~