https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> --- On Sun, 25 Jun 2023, crazylht at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237 > > --- Comment #9 from Hongtao.liu <crazylht at gmail dot com> --- > > > So we can simply clear only MEM_EXPR (and MEM_OFFSET), that cuts off the > > problematic part of alias analysis. Together with UNSPEC this might be > > enough to fix things. > > > Note maskstore won't optimized to vpblendd since it doesn't support memory > dest, so I guess no need to use UNSPEC for maskstore? A maskstore now looks like (insn 31 30 32 5 (set (mem:V8DF (plus:DI (reg/v/f:DI 108 [ a ]) (reg:DI 90 [ ivtmp.28 ])) [1 S64 A64]) (vec_merge:V8DF (reg:V8DF 115 [ vect__9.14 ]) (mem:V8DF (plus:DI (reg/v/f:DI 108 [ a ]) (reg:DI 90 [ ivtmp.28 ])) [1 S64 A64]) (reg:QI 100 [ loop_mask_57 ]))) "t.c":6:14 1957 {avx512f_storev8df_mask} that appears as a full read and a full store which means earlier stores to the masked part could be elided rightfully by RTL DSE at least. If there's any RTL analysis about whether a conditional load could trap then for example a full V8DF load from the same address that's currently conditional but after the above could be analyzed as safe to be scheduled speculatively and unconditional while it would not be safe as it could trap. I think the DSE issue is real and it should be easy to create a testcase like void foo (double *d, int mask) { d[5] = 1.; _intrinsic_for_mask_store (d, some-val, mask); } call that with lane 5 masked and check for d[5] = 1. preserved. I think RTL DSE will remove that store.
