[Bug target/86968] Unaligned big-endian (scalar_storage_order) access on armv7-a yields 4 ldrb instructions rather than ldr+rev

[ebotcazou at gcc dot gnu.org]

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.