https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92486
--- Comment #15 from Martin Jambor <jamborm at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #14) > On Fri, 15 Nov 2019, jamborm at gcc dot gnu.org wrote: > > [...] But yes, for your example we'd copy-prop out c and b which > might then have created "mismatching" accesses. Btw, I had > the impression that we propagate accesses from 'a' to b, c and d > in the above case, if we do we only have to add "fake" accesses > to the remaining parts? we do, as long as they do not interfere (create partial a overlap) with a pre-existing access. So if total scalarization created such an access, we would not. > > > > Assuming we almost never want to decrease the step size all the way to > > a char, this will not always help us to deal with the problem with > > overlapping scalar accesses. > > That's true, but if we do have scalar accesses then we can just reuse > those. For the original example with a char and an int and three > bytes padding when we originally have a char access we'd have to > come up with something for the three bytes padding. Right, slightly more context aware total scalarization might do that, and do that only when necessary. Basically it would add addition of accesses for total scalarization (almost) last. Hmmm, I'll need to think about all the implication of that. > > The case of fully contained sub-accesses is probably easy to handle > via BIT_FIELD_REFs Yeah, I backed out of doing that for reasons I no longer remember... > but when one access overlaps two others things > get interesting ... (two BIT_FIELD_REFs plus one BIT_INSERT_EXPR > for the combination). Code generation might also become awkward. ...but never even wanted to deal with these situations and still kind of don't :-)
