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? 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?
