qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] tcg/arm: Fix double-word comparisons


From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH] tcg/arm: Fix double-word comparisons
Date: Mon, 15 Jan 2018 08:18:55 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

On 01/15/2018 06:27 AM, Peter Maydell wrote:
> On 10 January 2018 at 05:39, Richard Henderson <address@hidden> wrote:
>> The code sequence we were generating was only good for unsigned
>> comparisons.  For signed comparisions, use the sequence from gcc.
>>
>> Fixes booting of ppc64 firmware, with a patch changing the code
>> sequence for ppc comparisons.
>>
>> Signed-off-by: Richard Henderson <address@hidden>
>> ---
>>  tcg/arm/tcg-target.inc.c | 112 
>> +++++++++++++++++++++++++++++++++--------------
>>  1 file changed, 80 insertions(+), 32 deletions(-)
>>
>> diff --git a/tcg/arm/tcg-target.inc.c b/tcg/arm/tcg-target.inc.c
>> index 98a1253..b9890c8 100644
>> --- a/tcg/arm/tcg-target.inc.c
>> +++ b/tcg/arm/tcg-target.inc.c
>> @@ -239,10 +239,11 @@ static void patch_reloc(tcg_insn_unit *code_ptr, int 
>> type,
>>      }
>>  }
>>
>> -#define TCG_CT_CONST_ARM  0x100
>> -#define TCG_CT_CONST_INV  0x200
>> -#define TCG_CT_CONST_NEG  0x400
>> -#define TCG_CT_CONST_ZERO 0x800
>> +#define TCG_CT_CONST_ARM     0x0100
>> +#define TCG_CT_CONST_INV     0x0200
>> +#define TCG_CT_CONST_NEG     0x0400
>> +#define TCG_CT_CONST_INVNEG  0x0800
>> +#define TCG_CT_CONST_ZERO    0x1000
>>
>>  /* parse target specific constraints */
>>  static const char *target_parse_constraint(TCGArgConstraint *ct,
>> @@ -258,6 +259,9 @@ static const char 
>> *target_parse_constraint(TCGArgConstraint *ct,
>>      case 'N': /* The gcc constraint letter is L, already used here.  */
>>          ct->ct |= TCG_CT_CONST_NEG;
>>          break;
>> +    case 'M':
>> +        ct->ct |= TCG_CT_CONST_INVNEG;
>> +        break;
> 
> In GCC constraint "M" is "integer in the range 0 to 32", which this clearly
> isn't. Can we have a comment saying what it is? (may be worth mentioning
> in particular how "rIM" differs from "rINK" -- I think the answer is that
> we want to say "valid-immediate OR (valid-if-inverted AND valid-if-negated)",
> whereas 'rINK' is "valid-immediate OR valid-if-inverted OR valid-if-negated".)

Exactly.

> The code looks OK to me. I'm guessing the sparc guest failure is
> just because we now generate more code for some of the comparison
> cases and that doesn't fit in the buffer...

I don't recall having seen a sparc failure...

> We could avoid the annoying "load LE/GE immediates to tempreg"
> extra code by having tcg_out_cmp2() return a flag to tell
> the caller which way round to put the conditions for its two
> conditional ARITH_MOV insns (for setcond2) or which condition
> to use for the branch (brcond2), right?

Um... we do return a condition.  I must have missed a trick or made a mistake
somewhere.


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]