Richard Guenther wrote:
Until the aggregates copy propagation is implemented, I think it would
better to disable full scalarization for such records. The patch is
attached. It's bootstrapped on x86_64-linux-gnu and regression tested.
Without looking at the patch I have two comments.
From reading your comments, I'm not sure if you're saying that you don't
like Jie's idea, or if you think it's an OK idea, but there are some
other things that you would like to see done as well or instead. It
would be helpful if you could make that clear.
To me, Jie's change seems like a plausible heuristic within the current
infrastructure. I'm all for building new infrastructure when
possible/necessary, but I don't think we should prevent these kinds of
tweaks to heuristics just because we can think of another way of doing
things. To me, the question ought to be "does this make the compiler
better for users?"
To answer that question, what I guess I'd like to know is what the
impact is on some benchmark that matters. Here, I don't think SPEC,
EEMBC, etc. are probably the right places to look; they probably don't
have much of this kind of code. Perhaps it would be interesting to know
how many SRA opportunities we lose in the Linux kernel because of this
change -- and then spot-check some of them to see whether those are
cases where we really lose by not doing SRA, or really win because we're
not doing the kind of ugly stuff that inspired this change.