Re: arm-elf bad code generation

[Richard Earnshaw <rearnsha at arm dot com>]

> The current version of GCC produces this assembler output for the attached 
> testcase (with -O2 -march=armv4 -fno-omit-frame-pointer) on arm-elf:
> 
> tcp_send:
>         @ args = 12, pretend = 0, frame = 32
>         @ frame_needed = 1, current_function_anonymous_args = 0
>         mov     ip, sp
>         stmfd   sp!, {r4, r5, r6, r7, r8, r9, sl, fp, ip, lr, pc}
>         sub     fp, ip, #4
>         ldr     ip, [fp, #12]
>         str     r1, [fp, #-44]
>         mov     r5, r0
>         mov     r1, #20
>         str     ip, [fp, #-56]
>         sub     sp, sp, #32   
>         strb    r1, [r5, #48]
>      
> [...]
> 
> The decrement of SP has been moved quite a long way down the function.  As a 
> result, there is a time during which arguments are stored on the stack at 
> locations below the current stack pointer.  A signal (or in my case interrupt, 
> since this testcase is derived from kernel code) corrupts this part of the 
> stack frame and hence the locals end up with the wrong value.
> 
> p.
> 
> 


Hmm, arm_expand_prologue inserts the following CLOBBER which is supposed 
to prevent moves across this point.  The question is, why doesn't it?  
Maybe it's an alias set problem, but I don't know the details of how that 
works.

  if (amount != const0_rtx)
    {
      insn = emit_insn (gen_addsi3 (stack_pointer_rtx, stack_pointer_rtx,
                                    amount));
      RTX_FRAME_RELATED_P (insn) = 1;
      emit_insn (gen_rtx_CLOBBER (VOIDmode, 
                                  gen_rtx_MEM (BLKmode, 
stack_pointer_rtx)));
    }