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.
