DSE and maskstore trouble

[Richard Biener]

On Tue, Jul 3, 2018 at 1:06 PM Andrew Stubbs <andrew_stubbs@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