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].
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.
