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: Kyrylo Tkachov <kyrylo dot tkachov at arm dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, nd <nd at arm dot com>
- Date: Fri, 10 Mar 2017 11:45:06 +0000
- Subject: Re: Right way to represent flag-setting arithmetic instructions in MD files
- Authentication-results: sourceware.org; auth=none
- Authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=arm.com;
- Nodisclaimer: True
- References: <58C27B9A.email@example.com> <20170310103811.GV22703@tucnak>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
<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:
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:
[(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"))
(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
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?