[Bug target/85434] Address of stack protector guard spilled to stack on ARM

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434

--- Comment #5 from Thomas Preud'homme <thopre01 at gcc dot gnu.org> ---
(In reply to Wilco from comment #4)
> Clearly rematerialization isn't working correctly. Immediates and constant
> addresses like this should never be spilled (using MOV/MOVK could increase
> codesize, but with -Os you should use the literal pool anyway). Check
> legitimate_constant_p returns true, see
> https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00052.html for how it's done
> on AArch64.

By the time LRA happens, this is what LRA sees of the address computation:

(insn 321 6 322 2 (set (reg:SI 274)
        (unspec:SI [
                (symbol_ref:SI ("__stack_chk_guard") [flags 0xc0] <var_decl
0x7f689803a2d0 __stack_chk_guard>)
            ] UNSPEC_PIC_SYM)) "test_arm_sp_fpic.c":41 181
{pic_load_addr_32bit}
     (expr_list:REG_EQUIV (unspec:SI [
                (symbol_ref:SI ("__stack_chk_guard") [flags 0xc0] <var_decl
0x7f689803a2d0 __stack_chk_guard>)
            ] UNSPEC_PIC_SYM)
        (nil)))
(insn 322 321 11 2 (set (reg/f:SI 175)
        (mem:SI (plus:SI (reg:SI 176)
                (reg:SI 274)) [0  S4 A32])) "test_arm_sp_fpic.c":41 876
{*thumb2_movsi_insn}
     (expr_list:REG_DEAD (reg:SI 274)
        (expr_list:REG_DEAD (reg:SI 176)
            (expr_list:REG_EQUIV (symbol_ref:SI ("__stack_chk_guard") [flags
0xc0] <var_decl 0x7f689803a2d0 __stack_chk_guard>)
                (nil)))))

It is this 175 which is spilled because LRA sees it doesn't have a register of
the right class to allocate that pseudo. Because it's a MEM it doesn't see it
as a constant expression and thus does not rematerialize it.