On Tue, Jul 3, 2018 at 1:57 PM Andrew Stubbs <andrew_stu...@mentor.com> wrote: > > On 03/07/18 12:45, Richard Biener wrote: > > On Tue, Jul 3, 2018 at 1:38 PM Andrew Stubbs <andrew_stu...@mentor.com> > > wrote: > >> > >> On 03/07/18 12:30, Richard Biener wrote: > >>>> 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. > >> > >> Right, but I have unrelated variables allocated to the stack within the > >> "shadow" of the masked vector. I didn't ask it to do that, it just does, > >> so I presume this is an expect feature of masked vectors with a known mask. > > > > Huh, I don't think so. I guess that's the real error and I wonder how > > that happens. > > Are those just spills or real allocations? > > The code from the testcase looks like this: > > struct rtattr rt[2]; > struct rtattr *rta[14]; > int i; > > rt[0].rta_len = sizeof (struct rtattr) + 8; > rt[0].rta_type = 0; > rt[1] = rt[0]; > for (i = 0; i < 14; i++) > rta[i] = &rt[0]; > > The initialization of rt[0] and rt[1] are being deleted because the > write to rta[0..13] would overwrite rt if it had actually been the > maximum rta[0..63].
Ok, so if we vectorize the above with 64 element masked stores then indeed the RTL representation is _not_ safe. That is because while the uses in the masked stores should prevent things from going bad there is also TBAA to consider which means those uses might not actually _be_ uses (TBAA-wise) of the earlier stores. In the above case rtattr * doesn't alias int (or whatever types rta_type or rta_len have). That means to DSE the earlier stores are dead. The fix would be to, instead of (match_dup 0) use (match_dup_but_change_MEM_ALIAS_SET_to_zero 0) ... at least for the expanders. That is, adjust the expanders to not use (match_dup 0) and add insn variants that also match alias-set zero (match_dup 0). Or sth along that lines. Richard. > That, or I've been staring at dumps too long and gone crazy. > > Andrew > > P.S. I'm trying to test with (match_dup 0), but LRA exploded.
