This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH GCC][1/2]Feed bound computation to folder in loop split
On Fri, 16 Jun 2017, Bin.Cheng wrote:
On Fri, Jun 16, 2017 at 5:16 PM, Richard Biener
On June 16, 2017 3:31:32 PM GMT+02:00, "Bin.Cheng" <firstname.lastname@example.org> wrote:
On Fri, Jun 16, 2017 at 2:10 PM, Richard Biener
On Fri, Jun 16, 2017 at 3:06 PM, Bin.Cheng <email@example.com>
On Fri, Jun 16, 2017 at 11:49 AM, Richard Biener
On Wed, Jun 14, 2017 at 3:07 PM, Bin Cheng <Bin.Cheng@arm.com>
Loop split forces intermediate computation to gimple operands all
the time when
computing bound information. This is not good since folding
missed. This patch fixes the issue by feeding all computation to
folder and only
forcing to gimple operand at last.
Bootstrap and test on x86_64 and AArch64. Is it OK?
Hm? It uses gimple_build () which should do the same as
fold_buildN in terms
So where does that not work? It is supposed to be the prefered way
new code should use force_gimple_operand (unless dealing with
coming from other middle-end infrastructure like SCEV or niter
Hmm, current code calls force_gimpele operand several times which
causes the inefficiency. The patch avoids that and does one call at
But it forces to the same sequence that is used for extending the
so folding should work. Where do you see that it does not? Note the
code uses gimple_build (), not gimple_build_assign ().
In spec2k6/hmmer, when building fast_algorithms.c with below command
./gcc -Ofast -S fast_algorithms.c -o fast_algorithms.S -fdump-tree-all
The lsplit dump contains:
<bb 11> [12.75%]:
_124 = _197 + 1;
_123 = _124 + -1;
_115 = MIN_EXPR <_197, _124>;
Which is generated here.
That means we miss a pattern in match.PD to handle this case.
I see. I will withdraw this patch and look in that direction.
For _123, we have
/* (A +- CST1) +- CST2 -> A + CST3
/* Associate (p +p off1) +p off2 as (p +p (off1 + off2)). */
For _115, we have
/* min (a, a + CST) -> a where CST is positive. */
/* min (a, a + CST) -> a + CST where CST is negative. */
(min:c @0 (plus@2 @0 INTEGER_CST@1))
(if (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0)))
(if (tree_int_cst_sgn (@1) > 0)
What is the type of all those SSA_NAMEs?