On 05/05/2016 08:03 AM, Shiva Chen wrote:
- /* We do not handle setting only part of the register. */
- if (DF_REF_FLAGS (adef) & DF_REF_READ_WRITE)
- return GRD_INVALID;
-
This isn't right, at least not without other changes. This prevents
using references where the register is set as part of a ZERO_EXTRACT or
STRICT_LOW_PART, and you seem not to handle such cases in the new code.
+/* Return rtx expression in INSN which calculate REG result. */
+
+static rtx
+get_reg_calculate_expr (rtx_insn *insn, rtx reg)
Hmm, that comment seems to be not quite accurate, though. The function
may return either the source of a SET that sets the register, or a MEM
(where it's not indicated whether the MEM is the source or destination
of the set, or whether the reg is set in the insn or is part of the address.
I think this interface is pretty bad. I think what you should do is
check in the caller whether the def is of READ_WRITE type. If so, do a
FOR_EACH_SUBRTX thing to look for a memory reference containing an
autoinc expression, otherwise this new function (without the MEM parts)
could be used. That'll also solve the problem above with the loss of
DF_REF_READ_WRITE checking.
The walk to find the appropriate MEM would be in a separate function,
used in the several places that
+ /* Find REG increment/decrement expr in following pattern
+
+ (parallel
+ (CC = compare (REG - 1, 0))
+ (REG = REG - 1))
+ */
Comment formatting, "*/" doesn't go on its own line. I think it's best
not to quote a pattern here since you're not actually looking for it. A
better comment would be "For identifying ivs, we can actually ignore any
other SETs occurring in parallel, so look for one with the correct
SET_DEST." I'm not actually sure, however, whether this is valid. It
would depend on how this information is used later on, and what
transformation other passes would want to do on the ivs. Come to think
of it, this is also true for autoinc ivs, but I guess these would only
appear when run late as analysis for modulo-sched, so I guess that would
be OK?
@@ -2354,6 +2489,20 @@ iv_number_of_iterations (struct loop *loop, rtx_insn
*insn, rtx condition,
goto fail;
op0 = XEXP (condition, 0);
+
+ /* We would use loop induction variable analysis
+ to get loop iteration count in SMS pass
+ which should work with/without doloop pass
+ active or not.
+
+ With doloop pass enabled, doloop pass would
+ generate pattern as (ne (REG - 1), 0) and
+ we recognize it by following code. */
+ if (GET_CODE (op0) == PLUS
+ && CONST_INT_P (XEXP (op0, 1))
+ && REG_P (XEXP (op0, 0)))
+ op0 = XEXP (op0, 0);
That really looks somewhat suspicious, and I can't really tell whether
it's right. My instinct says no; how can you just drop a constant on the
floor?
Bernd
