On Thu, Aug 23, 2012 at 11:51 AM, Chung-Lin Tang <clt...@codesourcery.com> wrote: > On 2012/8/23 05:08, Richard Guenther wrote: >>> First of all the warning should be probably issued from stor-layout.c >>> itself - see >>> other cases where we warn about packed structs. Yes, that means you'll >>> get the warning even when there is no access but you'll only get it a >>> single time. >>> >>> As of detecting whether a field is not aligned according to its mode, well, >>> that's impossible if you just look at the field or its containing type (and >>> thus >>> for a warning without false positives / negatives from stor-layout). It's >>> also >>> impossible to determine optimally (thus, it will say "not aligned according >>> to >>> its mode" in more cases). The way you detect such misalignment is, >>> given an access to such field, >>> >>> get_object_alignment (exp) < GET_MODE_ALIGNMENT (DECL_MODE (field)) >>> >>> when exp is a COMPONENT_REF with TREE_OPERAND (exp, 1) == field >>> and field has non-BLK mode. >>> >>> Note that an access a.f with f being a volatile field may be represented >>> by a volatile MEM_REF[&a, 16] where 16 is the byte offset relative to a. > > WRT only the code expansion aspects in store_fixed_bit_field(), would a > test of "STRICT_ALIGNMENT && MEM_ALIGN(op0) < GET_MODE_ALIGNMENT(mode)" > be sufficient to detect instead of a packedp parameter?
I suppose so. The code is there to ensure we don't use multiple smaller accesses, right? Accesses to outside of the field should be prohibited by properly computing DECL_BIT_FIELD_REPRESENTATIVE and all code specific to flag_strict_volatile_bitfields and that effect should be "moved" to stor-layout.c instead. Richard. > Chung-Lin > >>> Now, if you are only interested in bitfields (note, bitfields which fit a >>> mode >>> are _not_ bitfields as far as optimization passes are concerned and thus >>> may end up like above), then you probably want to look at >>> DECL_BIT_FIELD_REPRESENTATIVE of the FIELD_DECL of such field. >>> DECL_BIT_FIELD_REPRESENTATIVE constrains the offset / size said >>> field is to be accessed and you should call get_object_alignment with >>> a COMPONENT_REF using that field instead. You also want to make >>> sure DECL_BIT_FIELD_REPRESENTATIVE is computed correctly for >>> volatile bitfields on ARM (stor-layout computes that). >> >> In fact, you should probably implement code-generation constraints from >> within the frontends by, for strict volatile bitfields, emitting loads/stores >> using DECL_BIT_FIELD_REPRESENTATIVE (doing read-modify-write >> explicitely). Or maybe you can elaborate on the code-generation effects >> of strict-volatile bitfields? >
