Hi Kewen,
Cool stuff.
On Wed, Apr 24, 2019 at 04:41:01PM +0800, Kewen.Lin wrote:
> One failure was found in regression testing, which is:
> gcc.target/powerpc/20050830-1.c
>
> I did some investigation and found: with this patch, one new iv cand
> is chosen for exit condition, which is used to rewrite the compare
> type use. Later loop iv analysis in RTL can NOT determine the loop
> iteration number is finite, which causes doloop_optimize not transform
> the loop. The check doesn't find the expected pattern.
Does it create worse code now? What we have before your patch isn't
so super either (it has an sldi in the loop, it has two mtctr too).
Maybe you can show the generated code?
> Btw, this is for GCC10.
*Phew* ;-)
Some trivial comments:
> +static bool
> +invalid_insn_for_doloop_p (struct loop *loop)
> +{
> + basic_block *body = get_loop_body (loop);
> + unsigned num_nodes = loop->num_nodes;
> + gimple_stmt_iterator gsi;
> + unsigned i;
> +
> + for (i = 0; i < num_nodes; i++)
for (unsigned i = 0; i < num_nodes; i++)
(and maybe you can just say loop->num_nodes here; I don't know if that
generates worse code, or if that even matters).
> + if (dump_file && (dump_flags & TDF_DETAILS))
> + fprintf (
> + dump_file,
> + "predict doloop failure due to finding computed jump.\n");
We don't normally end lines in (. There are other solutions to why you
did that here; you can use string pasting, to break the string into two,
or factor out (some part of) the loop body to reduce indentation.
Segher
