https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968
--- Comment #13 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- > Forgive my naive question as I'm not too familiar with that part of the > compiler: why should the get_best_mem_extraction_insn be guarded with > reverse? I thought I'd just ad an if (reverse) if it succeeds and call > flip_storage_order there, likewise after the call to extract_bit_field_1 > below if successful. No, the numbering of bits depends on the endianness, i.e. you need to know the endianness of the source to do a correct extraction. For example, if you extract bit #2 - bit #9 of a structure in big-endian using HImode, then you cannot do it in little-endian and just swap the bytes afterwards (as a matter of fact, there is nothing to swap since the result is byte-sized). The LE extraction is: HImode load + HImode right_shift (2) whereas the BE extraction is: HImode load + HImode right_shift (6) The extv machinery cannot handle reverse SSO for the time being so the guard is still needed for it in the general case; on the contrary, extract_bit_field_1 can already and doesn't need an additional call to flip_storage_order. Of course, for specific bitfields, typically verifying simple_mem_bitfield_p, then you can extract in native order and do flip_storage_order on the result. In other words, the extv path can be used as you envision, but only for specific bitfields modeled on those accepted by simple_mem_bitfield_p, and then the call to flip_storage_order will indeed be needed.