This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] AVR: implement HI/SI logic operations and sign/zeroextension by define_insn_and_split ...


> From: Björn Haase <bjoern.m.haase@web.de>
>> - might splitting SI/DI mode operations down to HI mode prior to reload
>>   both enable the word oriented instructions addw/subw/movw/mul(word
>> result) to be leveraged while also providing more register allocation
>> flexibility for function calls etc, and then conditionally spit further
>> after reload insertion if determined to be beneficial (as I guess I don't
>> understand how once an HI mode add is split, it can easily be re-joined to
>> leverage an add word instruction for example if the required registers are
>> available, but not otherwise?)
> 
> Maybe, but I have doubts, whether it will be possible to extract useable
> condition codes from the expanded RTL:When expanding only towards HImode at
> expand time, gcc still would have to be able to recognize that it could
> simplify a sequence like
> 
> sub (low_word), sbc (high_word) cmp (low_word) cpc (high_word)
> conditional_branch
> 
> to 
> sub (low_word), sbc (high_word) conditional_branch
> 
> . Gcc would have to overlook a span of 5 Instructions! I don't think that this
> would work. IIRC, I have read something, that combine could join up to three
> instructions. You might have a look at the combine sources.?

It would seem that a way to avoid the explicit generic compares would be to
define compare operations on the (set CC) path of all operations which don't
generate them correctly; and then simply rely on GCC to optimize away dead
parallel paths without dependants. i.e.:

 (define_expand "xorsi3"
  [(set (subreg:QI (match_operand:SI 0 "register_operand" "=r") 0)
        (xor:QI (subreg:QI (match_operand:SI 1 "register_operand" "%0") 0)
                (subreg:QI (match_operand:SI 2 "register_operand" "r")  0)))
   (set (subreg:QI (match_dup 0) 1)
        (xor:QI (subreg:QI (match_dup 1) 1)
                (subreg:QI (match_dup 2) 1)))
   (set (subreg:QI (match_dup 0) 2)
        (xor:QI (subreg:QI (match_dup 1) 2)
                (subreg:QI (match_dup 2) 2)))
   (set (subreg:QI (match_dup 0) 3)
        (xor:QI (subreg:QI (match_dup 1) 3)
                (subreg:QI (match_dup 2) 3)))
   ;; define condition-code generation of result
   (set (reg:CC CC) (compare:si (match_dup 0)))]
  ""
  ...)

However no (compare ...) would required for expansions which generate
correct condition codes naturally like subtract, which need only specify:
 ...
 (set (reg:CC CC) (match_dup 0))]

This way all arithmetic and logical operations can be relied on to properly
specify how to set the condition code potentially required by a dependant
conditional branch, which are automatically optimized away if not required.
(it would seem)?




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]