[Bug rtl-optimization/88796] -fstack-protector* kills RTL DSE opportunities

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
We also use magic alias set e.g. directly in RTL DSE
(ALIAS_SET_MEMORY_BARRIER).

Anyway, there are multiple MEMs that need to be treated specially.  For the TLS
cases, it is e.g. on x86_64:
(insn 15 27 16 2 (parallel [
            (set (reg:CCZ 17 flags)
                (unspec:CCZ [
                        (mem/v/f/c:DI (plus:DI (reg/f:DI 19 frame)
                                (const_int -8 [0xfffffffffffffff8])) [3
D.1946+0 S8 A64])
                        (mem/f:DI (const_int 40 [0x28]) [4
MEM[(<address-space-1> long unsigned int *)40B]+0 S8 A64 AS1])
                    ] UNSPEC_SP_TEST))
            (clobber (scratch:DI))
        ]) "pr87370.c":23:1 978 {stack_protect_test_di}
     (nil))

so there is MEM_VOLATILE_P stack canary MEM where we could use a special
MEM_EXPR, after all, we apparently already have there a VAR_DECL, and can
check that in crtl->stack_protect_guard, so this part shouldn't be that hard,
except that we for some strange reason treat all volatile reads as killing
everything, so we'd need to ignore MEM_VOLATILE_P for that special case.  The
initial set ssp is a store to a volatile mem, so perhaps just ignoring such
MEMs altogether would DTRT.
The next thing is the TLS MEM, which has some MEM_EXPR in there (and isn't
volatile).  Can that use some magic VAR_DECL in MEM_EXPR instead of the
expression it uses?  It is weird that outside of MEM_EXPR it actually doesn't
record anywhere that it is another address space.  Can we ignore this MEM
altogether too?

Finally, with -mstack-protector-guard=global, we have e.g.:
(insn 13 25 14 2 (parallel [
            (set (reg:CCZ 17 flags)
                (unspec:CCZ [
                        (mem/v/f/c:DI (plus:DI (reg/f:DI 19 frame)
                                (const_int -8 [0xfffffffffffffff8])) [3
D.1946+0 S8 A64])
                        (mem/v/f/c:DI (symbol_ref:DI ("__stack_chk_guard")
[flags 0x40]  <var_decl 0x7f348fa555a0 __stack_chk_guard>) [3 __stack_ch
k_guard+0 S8 A64])
                    ] UNSPEC_SP_TEST))
            (clobber (scratch:DI))
        ]) "pr87370.c":23:1 978 {stack_protect_test_di}
     (nil))

so there is yet another MEM_VOLATILE_P memory.  Wonder why we are so
conservative about the volatile MEM reads, e.g. for a volatile MEM read from a
var I don't see why it should kill frame related stores.