On Thu, Aug 09, 2018 at 02:42:24PM -0700, Linus Torvalds wrote: > On Thu, Aug 9, 2018 at 2:24 PM Luc Van Oostenryck > <luc.vanoostenryck@xxxxxxxxx> wrote: > > > > I must say that I'm struggling a bit lately with the simplification > > of bitfield accesses and I'm more and more inclined to add bitfield > > insert & bit field extract instruction. It would help a lot but it > > would also force to duplicate or redo a lot of the simplifications > > already done for ASR/LSR/SH/AND/OR. > > I would really suggest against it. > > Turning bitfields into just plain memory accesses and shift-and-mask > operations as quickly as possible is almost certainly the right thing > to do. > > gcc special-cases bitfields way too much, and it has caused some very > nasty issues. See for example my ancient bug-report at > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696 > > which is also a strong argument for the whole "keep the base type > around, and do *not* think of it as just bits X-Y access", because it > turns out that the base type matters for both access size and for > access rules (ie volatile). Hehe, I'm in fact just busy to work on a bug that sparse has with volatile bitfields (the base type lost the volatile modifiers). > Now, I'm assuming you were thinking of just an "arithmetic" > insert/extract model (so separate from the memory access), and while > that at least avoids the access issues, I can pretty much guarantee > that it just makes for even more special cases and combinations than > just turning them into shift-and-mask operations. Yes, I didn't meant the memory access, only the shift/mask/combine part, like ARM64's BFI, BFXU & BFXS. They would indeed create new combinations that would need to simplify but they would have the big advantage to be single-intruction operationss while now a bitfield extract is 3 instructions (LSR + TRUNC + [SZ]EXT) and an insert is 4 instructions (SHL + 2 AND + OR) and it's the simplifications of these multi-instruction operations that is really painful, especially the insert. But since the current multi-instructions simplifications need anyway to be kept as they're also useful for non-bitfields, it would just add more work and more combinations and more code with very few in return (less instructions and pseudos at linearization time, faster simplification of bitfields). -- Luc
