This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH] Fix PR54733 Optimize endian independent load/store
- From: "Thomas Preud'homme" <thomas dot preudhomme at arm dot com>
- To: "GCC Patches" <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 19 May 2014 17:30:47 +0800
- Subject: RE: [PATCH] Fix PR54733 Optimize endian independent load/store
- Authentication-results: sourceware.org; auth=none
- References: <006f01cf6b71$1cf10df0$56d329d0$ at arm dot com> <000001cf70ee$9aa2ed90$cfe8c8b0$ at arm dot com> <CAFiYyc1-5KbvVXqiQKu3aVn_X0RKvvtJn4hBtADp5eA3QFEb4A at mail dot gmail dot com> <EF3B84D2-BB18-405B-8CE3-3C1F2A792473 at gmail dot com> <CAFiYyc360hKJvypP+qDwWF-7JM8dVj-gsVpnwGFMgNYo=taqMQ at mail dot gmail dot com> <CAFiYyc3ces083GJSR40pT4VCgtJpXn1hPSXk+1+jbnjORtb+-A at mail dot gmail dot com>
> From: Richard Biener [mailto:richard.guenther@gmail.com]
>
> Oh, and what happens for
>
> unsigned foo (unsigned char *x)
> {
> return x[0] << 24 | x[2] << 8 | x[3];
> }
>
> ? We could do an unsigned int load from x and zero byte 3
> with an AND. Enhancement for a followup, similar to also
> considering vector types for the load (also I'm not sure
> that uint64_type_node always has non-BLKmode for all
> targets).
I implemented this but it makes the statistics more difficult to read
and thus the test more difficult to write. Indeed, when doing a full
bswap many of the intermediate computations are partial bswap.
I can get on with it by using a different string to notify of partial
bswap than full bswap and test the partial bswap feature in a
separate file to not get noise from the full bswap. However I still
don't like the idea of notifying for partial bswap in statements that
will eventually be eliminated as dead statements. Besides, this
occur because some recursion is made for each statement even
if they were already examined which is not very nice in itself.
The solution I see is to keep a map of visited statements but I
don't know if that's fine in this case. After all, it's not strictly
necessary as the pass would work without this. It would just serve
to avoid redundant computation and confusion statistics.
Best regards,
Thomas