On Tue, Jul 3, 2018 at 1:06 PM Andrew Stubbs <andrew_stu...@mentor.com> wrote: > > On 03/07/18 12:02, Richard Biener wrote: > > I believe that the AVX variants like > > > > (define_expand "maskstore<mode><avx512fmaskmodelower>" > > [(set (match_operand:V48_AVX512VL 0 "memory_operand") > > (vec_merge:V48_AVX512VL > > (match_operand:V48_AVX512VL 1 "register_operand") > > (match_dup 0) > > (match_operand:<avx512fmaskmode> 2 "register_operand")))] > > "TARGET_AVX512F") > > > > are OK since they represent a use of the memory due to the match_dup 0 > > while your UNSPEC one doesn't so as the store doesn't actually take > > place to all of 0 your insn variant doesn't represent observable behavior. > > Hmm, so they're safe, but may prevent the optimization of nearby variables?
Yes, they prevent earlier stores into lanes that are "really" written to to be DSEd. > What about the unspec AVX variant? They also use match_dup 0 for an input to the UNSPEC so DSE should consider those similarly (as use). I think the non-unspec ones exist because AVX512 masks are integer registers and actually match the vec_merge requirements for the mask operand. For the AVX2 variants the mask is a regular vector which is where we do not have any suitable way to represent things on RTL. Well, maybe sth like (vec_select (vec_concat A B) (mult (const_vector -1 -2 -3 ...) mask-vector)) might work (not exactly, sth more complex is required). That said, a "vector"_cond_exec or some other variant of explicit masked-vector operation is really required to model this stuff exactly on RTL. Richard. > > Andrew
