On Fri, Oct 20, 2017 at 3:08 PM, Bin Cheng <bin.ch...@arm.com> wrote:
>
>
>
>
>
>
>
> From: Richard Biener <richard.guent...@gmail.com>
> Sent: 20 October 2017 12:24
> To: Bin Cheng
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH GCC][3/3]Refine CFG and bound information for split loops
>
> On Thu, Oct 19, 2017 at 3:26 PM, Bin Cheng <bin.ch...@arm.com> wrote:
>> Hi,
>> This is a rework of patch at  
>> https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01037.html.
>> The new patch doesn't try to handle all cases, instead, it only handles 
>> obvious cases.
>> It also tries to add tests illustrating different cases handled.
>> Bootstrap and test for patch set on x86_64 and AArch64.  Comments?
>
> ENOPATCH
>
> Sorry for the mistake, here is the one.

+  tree cmp_rslt = gimple_build (&tmp, cmp_code, boolean_type_node, border,
+                               gimple_convert (&tmp, TREE_TYPE (border),
+                                               newbound));
+  /* For case in which second loop must be executed, we only handle simple
+     case with unit step.  */
+  if (cmp_rslt != NULL_TREE

will always be non-NULL

+
+      gimple_seq_discard (tmp);
+      return border;
+    }
+
+  /* For newbound equals border case, we can handle arbitrary steps.  */
+  cmp_rslt = gimple_build (&tmp, EQ_EXPR, boolean_type_node, border, newbound);
+  gimple_seq_discard (tmp);

you are always discarding the built stmts so why are you building them?
This is a case for the fold_buildN () API given you are only simplifying
expressions?  Or for the tree-affine stuff though that doesn't handle
compares.

What is the difficulty for niter analysis to figure an upper bound for the
second loop?  Why isn't the generated condition for the second loop
optimized in the first place if it doesn't iterate?  Why do we generate
it at all in that case?  This is for loop-split-2?  Why is the condition
not removed by scalar passes?  It looks to me loop splitting isn't
the correct place to do this optimization.

Note that if we know the loop(s) do not iterate (zero latch executions)
we should eventually just peel for the code generation rather
than duplicating the loop and un-looping it later.

Thanks,
Richard.

> Thanks,
> bin
>
>> Thanks,
>> bin
>> 2017-10-16  Bin Cheng  <bin.ch...@arm.com>
>>
>>         * tree-ssa-loop-split.c (compute_new_first_bound): New parameter.
>>         Compute and return bound information for the second split loop.
>>         (adjust_loop_split): New function.
>>         (split_loop): Update use and call above function.
>>
>> gcc/testsuite/ChangeLog
>> 2017-10-16  Bin Cheng  <bin.ch...@arm.com>
>>
>>         * gcc.dg/loop-split-1.c: New test.
>>         * gcc.dg/loop-split-2.c: New test.
>>         * gcc.dg/loop-split-3.c: New test.
>

Reply via email to