https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Wilco from comment #27)
> (In reply to Eric Botcazou from comment #22)
> > > Is it really pure RTL, therefore not used in tree? So the above patch
> > > using
> > > BITS_BIG_ENDIAN for tree stuff would be incorrect to use it?
> >
> > I wouldn't say incorrect, just inappropriate and unnecessary. And, yes, it
> > isn't used at the tree level and should stay so IMO. BYTES_BIG_ENDIAN alone
> > already implicitly enforces a numbering on bits.
>
> I mean incorrect as in the optimization would still trigger and give
> incorrect results if BITS_BIG_ENDIAN == BYTES_BIG_ENDIAN (given that
> BITS_BIG_ENDIAN has no bearing on the bitfield offsets used on tree level).
Given that it matters for
/* If I2 is setting a pseudo to a constant and I3 is setting some
sub-part of it to another constant, merge them by making a new
constant. */
if (i1 == 0
...
if (GET_CODE (dest) == ZERO_EXTRACT)
{
...
if (BITS_BIG_ENDIAN)
offset = GET_MODE_PRECISION (dest_mode) - width - offset;
and VN tries to do sth similar I wonder if it does matter after all...
That said, the docs also refer to 'bit-field instructions' but do not
elaborate further -- I guess zero_extract is such but I'd have guessed
BIT_FIELD_REF (on trees) is as well. But yes, RTL expansion adjusts
things based on BITS_BIG_ENDIAN so it looks like GENERIC doesn't care
(or assumes BITS_BIG_ENDIAN == BYTES_BIG_ENDIAN).
