> The following patch adds BIT_FIELD_INSERT, an operation to > facilitate doing bitfield inserts on registers (as opposed > to currently where we'd have a BIT_FIELD_REF store).
Why not call it BIT_FIELD_INSERT_EXPR instead to make it clear that it's an expression and not a mere operation? > Originally this was developed as part of bitfield lowering > where bitfield stores were lowered into read-modify-write > cycles and the modify part, instead of doing shifting and masking, > be kept in a more high-level form to ease combining them. > > A second use case (the above is still valid) is vector element > inserts which we currently can only do via memory or > by extracting all components and re-building the vector using > a CONSTRUCTOR. For this second use case I added code > re-writing the BIT_FIELD_REF stores the C family FEs produce > into BIT_FIELD_INSERT when update-address-taken can otherwise > re-write a decl into SSA form (the testcase shows we miss > a similar opportunity with the MEM_REF form of a vector insert, > I plan to fix that for the final submission). The description in tree.def looks off then, it only mentions words and integral types. > One speciality of BIT_FIELD_INSERT as opposed to BIT_FIELD_REF > is that the size of the insertion is given implicitely via the > type size/precision of the value to insert. That avoids > introducing ways to have quaternary ops in folding and GIMPLE stmts. Yes, it's a bit unfortunate, but sensible. Maybe add a ??? note about that. -- Eric Botcazou
