Re: [Patch, MIPS] Modify memcpy.S for mips32r6/mips64r6

[OndÅej BÃlka <neleai at seznam dot cz>]

On Fri, Dec 19, 2014 at 03:02:37PM -0800, Steve Ellcey  wrote:
> Changes to memcpy and memset are the final patches I have for mips32r6
> and mips64r6 support.  This patch is the memcpy change.  In addition
> to adding mips32r6/mips64r6 support I fixed some indentation inconsistencies
> with preprocessor statements.
> 
> The main change is how to do memcpy when the source and destination cannot
> both be aligned.  For MIPS architectures prior to mips32r6 and mips64r6
> we aligned the destination and then used the ldl and ldr instructions to
> load unaligned words.  These instructions are not in mips32r6 or mips64r6
> so now we do two aligned word loads followed by an align instruction to
> combine the parts of the two loads into one register that can be stored
> into the previously aligned destination.
> 
> Tested with the mips32r6/mips64r6 GCC, binutils and qemu simulator.
> 
> OK to checkin?
> 
> Steve Ellcey
> sellcey@imgtec.com
> 

>  
> +#else /* R6_CODE */
> +
> +/* 
> + * Align the destination and hope that the source gets aligned too.  If it
> + * doesn't we jump to L(r6_unaligned*) to do unaligned copies using the r6
> + * align instruction.
> + */
> +	andi	t8,a0,7
> +	lapc	t9,L(atable)
> +	PTR_LSA	t9,t8,t9,2
> +	jrc	t9
> +L(atable):
> +	bc	L(lb0)
> +	bc	L(lb7)
> +	bc	L(lb6)

Same comment that jump table tends to be slow. Also is that faster than
storing these bytes unconditionally [1] or will it cause trouble in
processor that does not expect overlapping stores?

[1]

x[0] = y[0];
x[1] = y[1];
x[2] = y[2];
x[3] = y[3];
x[4] = y[4];
x[5] = y[5];
x[6] = y[6];
x[7] = y[7];