> From: Richard Biener [mailto:richard.guent...@gmail.com] > On Fri, May 16, 2014 at 12:07 PM, Thomas Preud'homme > <thomas.preudho...@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: pins...@gmail.com [mailto:pins...@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.guent...@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: pins...@gmail.com [mailto:pins...@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
