https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88796
--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> --- On January 10, 2019 8:49:58 PM GMT+01:00, "jakub at gcc dot gnu.org" <gcc-bugzi...@gcc.gnu.org> wrote: >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. Looks like DSE is too conservative here for no good reason? BTW, I'd prefer a alias analysis solution without special casing things in DSE.
