Re: [RFC] [P2] [PR tree-optimization/33562] Lowering more complex assignments.

[Jeff Law <law at redhat dot com>]

On 02/18/2016 02:56 AM, Richard Biener wrote:
> > Right.  But handling that has never been part of DSE's design goals. Once
> > there's a use, DSE has always given up.
>
> Yeah, which is why I in the end said we need a "better" DSE ...
Well, I don't see a rewrite/redesign in the mid-term horizon.


> > Having said that...
> >
> > > That is, you don't make use of the live_bytes in the
> > > ref_maybe_used_by_stmt_p
> > > check (you can skip uses of only dead bytes).
> > >
> > > Not sure if it makes a difference in practice (compared to the cost it
> > > would take).
> >
> > Not sure either.  It doesn't appear that it would be hard to experiment with
> > that to see if it's worth the effort.  My gut feeling is we're not going to
> > see this often, if at all, in practice.
>
> Yeah, I think the case we're after and that happens most is sth like
>
>   a = { aggregate init };
>   a.a = ...;
>   a.b = ...;
>   ...
>
> and what you add is the ability to remove the aggregate init completely.
Essentially, yes.

> What would be nice to have is to remove it partly as well, as for
>
> struct { int i; int j; int k; } a = {};
> a.i = 1;
> a.k = 3;
>
> we'd like to remove the whole-a zeroing but we need to keep zeroing
> of a.j.
>
> I believe that SRA already has most of the analysis part, what it is
> lacking is that SRA works not flow-sensitive (it just gathers
> function-wide data) and that it doesn't consider base objects that
> have their address taken or are pointer-based.
I guess we could look at the live bytes at the end of the loop in 
dse_possible_dead_store_p and perhaps re-write the original statement.



> That said, your patch addresses a very specific case nothing else in
> the compiler
> handles right now, but it's also quite limited.  So evaluating the compile-time
> impact is important here as well as trying to cover more cases of "partial inits
> after full inits" optimization.
It's fairly narrow.  Most of the stuff it's finding are just the 
clobbers and removing those is totally uninteresting from a code 
generation standpoint.

I'm going to do another round of statistics gathering, filtering out all 
the clobbers.  Some light poking would indicate there's still real world 
codes where this will help (in libstdc++, not surprisingly), but it's 
not going to be as broad as I'd like.

> I don't believe we need to rush this into GCC 6.
Not looking to rush this -- it seems simple enough and fixes a long 
standing regression.  I think it's appropriate, but I'm not going to get 
bent out of shape if you disagree and we table it until GCC 7.

jeff