This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix PR54733 Optimize endian independent load/store
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: "Thomas Preud'homme" <thomas dot preudhomme at arm dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 19 May 2014 11:46:26 +0200
- 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> <000101cf7345$05da1630$118e4290$ at arm dot com>
On Mon, May 19, 2014 at 11:30 AM, Thomas Preud'homme
>> From: Richard Biener [mailto:email@example.com]
>> Oh, and what happens for
>> unsigned foo (unsigned char *x)
>> return x << 24 | x << 8 | x;
>> ? 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
> 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.
Ah, indeed ...
> 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.
... having bswap cleanup after itself (thus remove dead code itself
would be nice). Let's just keep the above as a possibility for
further enhancements and focus on getting the current patch
correct and committed.
Btw, another enhancement is memory target. Thus recognize
void bswap_mem (char *m1, char *m2)
m2 = m1;
m2 = m1;
m2 = m1;
m2 = m1;
with all the complication that arises due to aliasing issues.
> Best regards,