On 31/01/18 19:04, Richard Sandiford wrote:
> Eric Botcazou <ebotca...@adacore.com> writes:
>>> Tested on SPARC64/Linux and ARM/EABI, applied on mainline and 7 branch.
>>
>> As discussed in the audit trail, this beefs up the internal documentation 
>> about WORD_REGISTER_OPERATIONS.
>>
>> Tested with 'make doc', applied on mainline and 7 branch.
>>
>>
>> 2018-01-31  Eric Botcazou  <ebotca...@adacore.com>
>>
>>      PR rtl-optimization/84071
>>      * doc/tm.texi.in (WORD_REGISTER_OPERATIONS): Add explicit case.
>>      * doc/tm.texi: Regenerate.
>>
>> Index: doc/tm.texi.in
>> ===================================================================
>> --- doc/tm.texi.in   (revision 257227)
>> +++ doc/tm.texi.in   (working copy)
>> @@ -7376,8 +7376,12 @@ is in effect.
>>
>>  @defmac WORD_REGISTER_OPERATIONS
>>  Define this macro to 1 if operations between registers with integral mode
>> -smaller than a word are always performed on the entire register.
>> -Most RISC machines have this property and most CISC machines do not.
>> +smaller than a word are always performed on the entire register.  To be
>> +more explicit, if you start with a pair of @code{word_mode} registers with
>> +known values and you do a subword, for example @code{QImode}, addition on
>> +the low part of the registers, then the compiler may consider that the
>> +result has a known value in @code{word_mode} too if the macro is defined
>> +to 1.  Most RISC machines have this property and most CISC machines do not.
> 
> By QImode addition, do you mean:
> 
>    (set (subreg:QI (reg:SI X1) N)
>       (plus:QI (subreg:QI (reg:SI X2) N)
>                (subreg:QI (reg:SI X3) N)))
> 
> ?  I thought the point was instead that the target expected such ops
> to be done on word_mode, even if the values involved are naturally QImode:
> 
>    (set (subreg:SI (reg:QI Y1) 0)
>       (plus:SI (subreg:SI (reg:QI Y2) 0)
>                (subreg:SI (reg:QI Y3) 0)))
> 
> Most RISC/WORD_REGISTER_OPERATIONS targets wouldn't provide QImode
> addition patterns, so the first insn seems unlikely.
> 
> Thanks,
> Richard
> 

That's always been my interpretation too.  Seems like we may be changing
the meaning of this macro...

R.

Reply via email to