Re: [PATCH 5/7] MIPS: Fix microMIPS LL/SC immediate offsets

["Steven J. Hill" <Steven.Hill@imgtec.com>]

On 11/15/2014 04:08 PM, Maciej W. Rozycki wrote:
> In the microMIPS encoding some memory access instructions have their 
> immediate offset reduced to 12 bits only.  That does not match the GCC 
> `R' constraint we use in some places to satisfy the requirement, 
> resulting in build failures like this:
> 
> {standard input}: Assembler messages:
> {standard input}:720: Error: macro used $at after ".set noat"
> {standard input}:720: Warning: macro instruction expanded into multiple instructions
> 
> Fix the problem by defining a macro, `GCC_OFF12_ASM', that expands to 
> the right constraint depending on whether microMIPS or standard MIPS 
> code is produced.  Also apply the fix to where `m' is used as in the 
> worst case this change does nothing, e.g. where the pointer was already 
> in a register such as a function argument and no further offset was 
> requested, and in the best case it avoids an extraneous sequence of up 
> to two instructions to load the high 20 bits of the address in the LL/SC 
> loop.  This reduces the risk of lock contention that is the higher the 
> more instructions there are in the critical section between LL and SC.
> 
> Strictly speaking we could just bulk-replace `R' with `ZC' as the latter 
> constraint adjusts automatically depending on the ISA selected.  
> However it was only introduced with GCC 4.9 and we keep supporing older 
> compilers for the standard MIPS configuration, hence the slightly more 
> complicated approach I chose.
> 
> The choice of a zero-argument function-like rather than an object-like 
> macro was made so that it does not look like a function call taking the 
> C expression used for the constraint as an argument.  This is so as not 
> to confuse the reader or formatting checkers like `checkpatch.pl' and 
> follows previous practice.
> 
> Signed-off-by: Maciej W. Rozycki <macro@codesourcery.com>
> ---
> 
I am extremely pleased with this patch. We had discussed this problem
and various potential solutions a year or two ago, but I was never able
to find time to look at it again. Thanks for figuring this out.


Signed-off-by: Steven J. Hill <Steven.Hill@imgtec.com>