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 10:49:03 +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> <9D10C3AA-1886-4B57-AD1C-791F5C489CA6 at gmail dot com>
> From: Richard Biener [mailto:richard.guenther@gmail.com]
> On Fri, May 16, 2014 at 12:07 PM, Thomas Preud'homme
> <thomas.preudhomme@arm.com> wrote:
> > Ping?
>
> Sorry ...
>
> Thanks and sorry again for the delay.
>
No need to be sorry, it was really not meant as a complaint. I understand very
well that patches sometimes go under the radar and I just wanted to make
sure someone saw it.
> From: pinskia@gmail.com [mailto:pinskia@gmail.com]
>
> Not always decomposed. On MIPS, it should using the load/store left/right
> instructions for unaligned load/stores which is normally better than
> decomposed load/stores. So having a cost model would be nice.
>
This makes me think about the following situation:
uint32_t
read_le (unsigned char data[])
{
uint16_t lo, hi;
hi = data[0] | (data[1] << 8);
lo = (data[2] << 16) | (data[3] << 24);
printf ("lo + hi: %d\n", lo + hi);
return hi | lo;
}
Currently this will do a load of 4 bytes and do a bswap on big endian target but
It would be better to just handle hi and lo separately doing two 2 bytes load
and doing a bitwise OR of these two. So check if two SSA_NAME are used by
other statements and if yes stop there.
> 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).
>
Looks like a nice improvement to the patch indeed.
> From: pinskia@gmail.com [mailto:pinskia@gmail.com]
>
> No we cannot if x[4] is on a different page which is not mapped in, we get a
> fault. Not something we want.
>
Why would x[4] be loaded? I guess Richard was only suggesting doing a single
load + zeroing only when the untouched array entry is neither the first nor the
last, that is when there is a load.
Best regards,
Thomas Preud'homme