This is the mail archive of the gcc@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: Right way to represent flag-setting arithmetic instructions in MD files


<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


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