From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 8D6C93856DCA for ; Thu, 11 May 2023 04:50:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8D6C93856DCA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id AF8EB1063; Wed, 10 May 2023 21:50:46 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 970393F663; Wed, 10 May 2023 21:50:01 -0700 (PDT) From: Richard Sandiford To: =?utf-8?B?6ZKf5bGF5ZOy?= Mail-Followup-To: =?utf-8?B?6ZKf5bGF5ZOy?= ,gcc-patches , rguenther , richard.sandiford@arm.com Cc: gcc-patches , rguenther Subject: Re: [PATCH V4] VECT: Add decrement IV iteration loop control by variable amount support References: <20230504132540.286148-1-juzhe.zhong@rivai.ai> <6FF047D0528730E9+202305110500425721249@rivai.ai> <98928AAE69C76AC2+2023051106510044600911@rivai.ai> Date: Thu, 11 May 2023 05:50:00 +0100 In-Reply-To: <98928AAE69C76AC2+2023051106510044600911@rivai.ai> (=?utf-8?B?IumSn+WxheWTsiIncw==?= message of "Thu, 11 May 2023 06:51:01 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-22.2 required=5.0 tests=BAYES_00,BODY_8BITS,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: =E9=92=9F=E5=B1=85=E5=93=B2 writes: > I am sorry that I am still confused about that. > > Is this what you want ? > > bool use_minus_p =3D TREE_CODE (step) =3D=3D INTEGER_CST && ((TYPE_UNSI= GNED (TREE_TYPE (step)) && tree_int_cst_lt (step1, step)) > || (!TYPE_UNSIGNED (TREE_TYPE (step)) && !tree_expr_= nonnegative_warnv_p (step, &ovf) && may_negate_without_overflow_p (step))); > > /* For easier readability of the created code, produce MINUS_EXPRs > when suitable. */ > if (TREE_CODE (step) =3D=3D INTEGER_CST) > { > if (TYPE_UNSIGNED (TREE_TYPE (step))) > { > step1 =3D fold_build1 (NEGATE_EXPR, TREE_TYPE (step), step); > if (tree_int_cst_lt (step1, step)) > { > incr_op =3D MINUS_EXPR; /* Remove it. */ > step =3D step1; > } > } > else > { > bool ovf; > > if (!tree_expr_nonnegative_warnv_p (step, &ovf) > && may_negate_without_overflow_p (step)) > { > incr_op =3D MINUS_EXPR; /* Remove it. */ > step =3D fold_build1 (NEGATE_EXPR, TREE_TYPE (step), step); > } > } > } > if (POINTER_TYPE_P (TREE_TYPE (base))) > { > if (TREE_CODE (base) =3D=3D ADDR_EXPR) > mark_addressable (TREE_OPERAND (base, 0)); > step =3D convert_to_ptrofftype (step); > if (incr_op =3D=3D MINUS_EXPR) /* Change it into if (use_minus_p) = */ > step =3D fold_build1 (NEGATE_EXPR, TREE_TYPE (step), step); > incr_op =3D POINTER_PLUS_EXPR; /* Remove it. */ > } > /* Gimplify the step if necessary. We put the computations in front of= the > loop (i.e. the step should be loop invariant). */ > step =3D force_gimple_operand (step, &stmts, true, NULL_TREE); > if (stmts) > gsi_insert_seq_on_edge_immediate (pe, stmts); >=20=20=20 > if (POINTER_TYPE_P (TREE_TYPE (base))) > stmt =3D gimple_build_assign (va, POINTER_PLUS_EXPR, vb, step); > else if (use_minus_p) > stmt =3D gimple_build_assign (va, MINUS_EXPR, vb, step); > else > stmt =3D gimple_build_assign (va, incr_op, vb, step); > ... > > Since I have no idea to make stmts flips between PLUS_EXPR and MINUS_EXPR. No, I meant: - Rename the "code" argument to "incr_op". - Remove "tree_code incr_op =3D code;". - Replace both instances of: incr_op =3D MINUS_EXPR; with: incr_op =3D (incr_op =3D=3D PLUS_EXPR ? MINUS_EXPR : PLUS_EXPR); The point is that the current code (rightly) assumes that incr_op always starts out as PLUS_EXPR, i.e. that STEP starts out applying positively. Making STEP apply in the opposite direction is then as simple as changing incr_op to MINUS_EXPR. But the new interface allows STEP to start out applying positively or negatively, and so this code needs to cope with both cases. Thanks, Richard