This is the mail archive of the
mailing list for the GCC project.
Re: Right way to represent flag-setting arithmetic instructions in MD files
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 10 Mar 2017 11:38:11 +0100
- Subject: Re: Right way to represent flag-setting arithmetic instructions in MD files
- Authentication-results: sourceware.org; auth=none
- References: <58C27B9A.email@example.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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)
> (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