This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH] Fix PR54733 Optimize endian independent load/store


> 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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]