Re: [RFA] [PR tree-optimization/33562] [PATCH 1/4] Byte tracking in DSE

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 16 Dec 2016, Jakub Jelinek wrote:

> On Fri, Dec 16, 2016 at 06:35:58PM +0000, Joseph Myers wrote:
> > On Thu, 15 Dec 2016, Jeff Law wrote:
> > 
> > > This version attacks the problem by improving DSE to track stores to memory at
> > > a byte level.  That allows us to determine if a series of stores completely
> > > covers an earlier store (thus making the earlier store dead).
> > 
> > Question: suppose you have an assignment for a struct with padding, then 
> > stores for all the elements.  Does it detect that the original assignment 
> > is dead (because there is no need to copy padding on struct assignment)?
> 
> We fold memcpy into struct assignment early, does the same apply also to
> memcpy?  Or shall we fold memcpy into struct assignment only when there is
> no padding (or find different IL representation of that)?

There is at least an arguable case that memset needs to set padding to 0 
(unlike initializers), and memcpy needs to copy it (unlike struct 
assignment).  Atomic compare-exchange definitely needs to work on the 
whole representation including padding.

However, when you store in a member of a structure (or union), that 
results in all the padding becoming undefined.  So in the cases of memcpy 
/ memset where this optimization is interesting (element stores follow the 
memcpy / memset), you can still optimize.

(Note the desire for an option to avoid such padding-related 
optimizations, by treating padding for optimization purposes as if there 
were dummy fields there that can all be cleared by a {} initializer or 
memset: PR 77992.)

-- 
Joseph S. Myers
joseph@codesourcery.com