<resending for 3rd time. Sorry my email system is having trouble :(>
On 10/03/17 10:38, Jakub Jelinek wrote:
On Fri, Mar 10, 2017 at 10:10:34AM +0000, Kyrill Tkachov wrote:
Hi all,

Some (many?) targets have instructions that perform an arithmetic operation and 
set the condition flags based on the result.
For example, on aarch64, we have instructions like ADDS, SUBS, ANDS etc.
In the machine description we represent them as a PARALLEL pattern of a COMPARE 
and the arithmetic operation.
For example, the ADDS instruction is represented as:

(define_insn "add<mode>3_compare0"
   [(set (reg:CC_NZ CC_REGNUM)
     (compare:CC_NZ
      (plus:GPI (match_operand:GPI 1 "register_operand" "%r,r,r")
            (match_operand:GPI 2 "aarch64_plus_operand" "r,I,J"))
      (const_int 0)))
    (set (match_operand:GPI 0 "register_operand" "=r,r,r")
     (plus:GPI (match_dup 1) (match_dup 2)))]

My understanding was that the order of the two in this pattern here doesn't 
matter because there is
an implicit PARALLEL around them, but I found that the compare-elimination pass 
(compare-elim.c)
assumes that the COMPARE set must be in the second position for it to do the 
transformations it wants.

Is there a recommended order for specifying the compare and the arithmetic 
operation in the MD files?
(in which case we should go through the aarch64 MD files and make sure the 
patterns are written the right
way round). Or is the compare-elimination pass just not robust enough? (In 
which case we should teach it
to look into both SETs of the pattern).
Please see http://gcc.gnu.org/ml/gcc-patches/2014-12/msg00584.html and
surrounding thread.


Thanks, that is helpful.
It seems to me that teaching cmpelim to handle either order would not be a very 
complicated task.
Would folks object to making such a change?

Kyrill

        Jakub

Reply via email to