Re: rs6000 stack_tie mishap again

[Olivier Hainque <hainque@adacore.com>]

Hello Segher,

> On Mar 28, 2016, at 13:18 , Segher Boessenkool <segher@kernel.crashing.org> wrote:
> 
>> You need to have had r11 last used to designate a global
>> symbol as part of the function body (in order to have base_term
>> designate a symbol_ref etc), and then have the scheduler
>> decide that moving across is a good idea. It's certainly not
>> an easy combination to trigger.
> 
> Yes, I did that (with some asm's).  Like this:
> 
> ===
> void g(int, char *);
> 
> int dum;
> 
> void f(int x)
> {
>        char big[200000];
>        g(x, big);
>        g(x, big);
>        register void *p asm("r11") = &dum;
>        asm("" : : "r"(p));
> }

Ah, I see, thanks. In this instance, the problem doesn't
trigger because CONSTANT_POOL_ADDRESS_P (base) is false in

  base = find_base_term (true_mem_addr);
  if (! writep
      && base
      && (GET_CODE (base) == LABEL_REF
	  || (GET_CODE (base) == SYMBOL_REF
	      && CONSTANT_POOL_ADDRESS_P (base))))
    return 0;

  (part of write_dependence_p)

With a minor variation:

void g(int, char *);

void f(int x)
{
       char big[200000];
 start:
       g(x, big);
       g(x, big);
       register void *p asm("r11") = &&start;
       asm("" : : "r"(p));
       asm("" : : :"r28");
       asm("" : : :"r29");
       asm("" : : :"r30");
}

I'm getting:

        lis 11,.L2@ha
        la 11,.L2@l(11)

        lwz 11,0(1)
        lwz 0,4(11)
        lwz 28,-16(11) 

	mr 1,11

	mtlr 0
	lwz 29,-12(11)
	lwz 30,-8(11)
	lwz 31,-4(11)

	blr

out of a powerpc-elf close-to-tunk compiler, despite the
presence of a stack_tie insn at the rtl level.

Olivier