[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc-patches
Subject:    Re: [PATCH v2 3/9] aarch64: Add <su>cmp_*_carryinC patterns
From:       Richard Henderson via Gcc-patches <gcc-patches () gcc ! gnu ! org>
Date:       2020-03-31 22:44:51
Message-ID: e87f5d57-a574-387f-5a84-5bbc0b0ccdb7 () linaro ! org
[Download RAW message or body]

On 3/31/20 11:34 AM, Richard Sandiford wrote:
>> +(define_insn "*<ANY_EXTEND:su>cmp<GPI:mode>3_carryinC"
>> +  [(set (reg:CC CC_REGNUM)
>> +	(compare:CC
>> +	  (ANY_EXTEND:<DWI>
>> +	    (match_operand:GPI 0 "register_operand" "r"))
>> +	  (plus:<DWI>
>> +	    (ANY_EXTEND:<DWI>
>> +	      (match_operand:GPI 1 "register_operand" "r"))
>> +	    (match_operand:<DWI> 2 "aarch64_borrow_operation" ""))))]
>> +   ""
>> +   "sbcs\\t<w>zr, %<w>0, %<w>1"
>> +  [(set_attr "type" "adc_reg")]
>> +)
> 
> I guess this feeds into your reply to Segher's comment for 7/9,
> but I think:
> 
>    (compare:CC X Y)
> 
> is always supposed to be the NZCV flags result of X - Y, as computed in
> the mode of X and Y.  If so, it seems like the type of extension should
> matter.  E.g. the N flag ought to be set for:
> 
>   (compare:CC
>     (sign_extend 0xf...)
>     (plus (sign_extend 0x7...)
>           (ltu ...)))
> 
> but ought to be clear for:
> 
>   (compare:CC
>     (zero_extend 0xf...)
>     (plus (zero_extend 0x7...)
>           (ltu ...)))
> 
> If so, I guess this is a bug in the existing code...

The subject of CCmodes is a sticky one.  It mostly all depends on what combine
is able to do with the patterns.

For instance, your choice of example above, even for signed, the N bit cannot
be examined by itself, because that would only be valid for a comparison
against zero, like

    (compare (plus (reg) (reg))
             (const_int 0))

For this particular bit of rtl, the only valid comparison is N == V, i.e. GE/LT.

If we add a new CC mode for this, what would you call it?  Probably not
CC_NVmode, because to me that implies you can use either N or V, but it doesn't
imply you must examine both.

If we add more CC modes, does that mean that we have to improve SELECT_CC_MODE
to match those patterns?  Or do we add new CC modes just so that combine's use
of SELECT_CC_MODE *cannot* match them?


r~
[prev in list] [next in list] [prev in thread] [next in thread]