[Bug target/86968] Unaligned big-endian (scalar_storage_order) access on armv7-a yields 4 ldrb instructions rather than ldr+rev
thopre01 at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Tue Oct 9 17:16:00 GMT 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968
--- Comment #9 from Thomas Preud'homme <thopre01 at gcc dot gnu.org> ---
(In reply to Thomas Preud'homme from comment #8)
> (In reply to Thomas Preud'homme from comment #7)
> > (In reply to Thomas Preud'homme from comment #6)
> > > Happens at expand time. Diving in.
> >
> > There's a giant if in expand_expr_real_1 with the following comment:
> >
> > /* In cases where an aligned union has an unaligned object
> > as a field, we might be extracting a BLKmode value from
> > an integer-mode (e.g., SImode) object. Handle this case
> > by doing the extract into an object as wide as the field
> > (which we know to be the width of a basic mode), then
> > storing into memory, and changing the mode to BLKmode. */
> >
> > The "if" is entered in the big endian unaligned case but not in the other
> > case. In the aligned case, it continues after the if until the call to
> > flip_storage_order which will generate the bswap.
>
> In the aligned case, the if is not taken because alignment of the memory Vs
> access is sufficient. There is provision to call flip_storage_order but only
> if the access is a RECORD and here the mode class is INT.
>
> Therefore unaligned access are handled by extract_bit_field. This in turns
> call extract_bit_field_1 and later extract_integral_bit_field where things
> are different between little endian and big endian. For little endian, it
> goes in the following if block:
>
> /* If OP0 is a memory, try copying it to a register and seeing if a
> cheap register alternative is available. */
> if (MEM_P (op0) & !reverse)
>
> For big endian it continues and calls extract_fixed_bit_field. I'm wondering
> if an extra call to flip_storage_order when reverse is true would solve the
> issue. Need to understand better whe is it safe to call flip_storage_order.
It gives me the expected assembly but I need to convince myself that this is
always safe.
More information about the Gcc-bugs
mailing list