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
jos...@codesourcery.com
