efriedma-quic wrote: > Hm, I've been thinking of it the opposite way round -- merging bitfields is > throwing away information (about where cuts might be).
In essence, late optimizations can make accesses narrower, but it can't make them wider. The information about cuts is generally recoverable by analyzing the masking instructions. ------ When I refer to CSE/DSE, I'm mostly talking about keeping values in registers for longer. They don't know anything about individual fields in bitfields. If we split bitfields too narrowly, we end up with extra memory accesses for accessing multiple adjacent fields. And if you have accesses which overlap (access some, but not all, of the same memory), CSE/DSE get much worse. Having a bitfield unit that can't be loaded in a single memory access probably doesn't have much benefit, if there's a natural boundary we can use to split. > Certainly, by could you clarify why changing the access patterns could do > that? My understanding of Poison is that should they cause a user-visible > state change, that's indicative of the original progam's UB, and the > languages in question don't guarantee anything at that point -- nasal demons > and all. That the observed behaviour of a UB-exhibiting program changes is > not a defect. What am I missing? Depending on how we fix the interaction between poison and bitfields, there could be an invariant that accessing any bitfield has to freeze all adjacent bitfield values. If we do that, then the set of "adjacent" values actually matters. There's probably some way we can make this work without actually introducing memory accesses, though; probably not worth worrying about too much here. https://github.com/llvm/llvm-project/pull/65742 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
