https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |thomas.preudhomme at arm dot
com
--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> ---
c.f. comment#24 and using bswap for this kind of value composition
gu (unsigned char c)
{
short unsigned int y.7_2;
signed short y.8_3;
signed short _4;
int _6;
int _7;
signed short _8;
signed short _9;
short unsigned int y.9_10;
<bb 2>:
y.7_2 = y;
y.8_3 = (signed short) y.7_2;
_4 = y.8_3 & 255;
_6 = (int) c_5(D);
_7 = _6 << 8;
_8 = (signed short) _7;
_9 = _4 | _8;
y.9_10 = (short unsigned int) _9;
y = y.9_10;
return;
this could be
BIT_FIELD_REF <y, ....> = c_5;
or if not both stores and loads are seen at least
y.7_2 = y;
y.9_10 = BIT_FIELD_EXPR <y.7_2, ..., c_5(D)>;
y = y.9_10;
with the new BIT_FIELD_EXPR code I proposed some time ago for bitfield
insertion.
Technically not limited to byte offsets of course, so maybe not a 100%
fit for the bswap pass. And of course the BIT_FIELD_EXPR would still
need to be expanded properly (extv/insv support would fit naturally).
Without BIT_FIELD_EXPR the bswap pass could see if the final value
has a single use in a store and then still use a BIT_FIELD_REF on that.
