This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/79830] GCC generates counterproductive code surrounding very simple loops (improvement request)
- From: "amker at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 10 May 2017 10:27:46 +0000
- Subject: [Bug tree-optimization/79830] GCC generates counterproductive code surrounding very simple loops (improvement request)
- Auto-submitted: auto-generated
- References: <bug-79830-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79830
--- Comment #5 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> It is induction variable optimization (-fivopts) that re-writes the main
> induction variable. We have
>
> Original cost 17 (complexity 2)
>
> Final cost 17 (complexity 2)
>
> Selected IV set for loop 2 at t.C:44, 4 avg niters, 0 expressions, 1 IVs:
> Candidate 5:
> Var befor: ivtmp.25_108
> Var after: ivtmp.25_107
> Incr POS: before exit test
> IV struct:
> Type: sizetype
> Base: 0
> Step: 32
> Biv: N
> Overflowness wrto loop niter: No-overflow
>
> Replacing exit test: if (i_32 >= 0)
>
> but it doesn't seem to account the extra cost for the exit test replacement
> when facing equal original/final cost.
For the iv elimination issue, I think it's simply a bug in computing
elimination cost:
/* When the condition is a comparison of the candidate IV against
zero, prefer this IV.
TODO: The constant that we're subtracting from the cost should
be target-dependent. This information should be added to the
target costs for each backend. */
if (!elim_cost.infinite_cost_p () /* Do not try to decrease infinite! */
&& integer_zerop (*bound_cst)
&& (operand_equal_p (*control_var, cand->var_after, 0)
|| operand_equal_p (*control_var, cand->var_before, 0)))
elim_cost -= 1;
Why it compares against current bound_cst for elim_cost? After elimination, we
don't compare against bound_cst any more (very likely)!