This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [Patch for suggestions]: How do we know a loop is the peeled version?
- From: "Fang, Changpeng" <Changpeng dot Fang at amd dot com>
- To: Zdenek Dvorak <rakdver at kam dot mff dot cuni dot cz>
- Cc: Richard Guenther <richard dot guenther at gmail dot com>, Sebastian Pop <sebpop at gmail dot com>, Christian Borntraeger <borntraeger at de dot ibm dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "uweigand at de dot ibm dot com" <uweigand at de dot ibm dot com>
- Date: Fri, 2 Jul 2010 19:02:28 -0500
- Subject: RE: [Patch for suggestions]: How do we know a loop is the peeled version?
- References: <20100701193818.GB13423@kam.mff.cuni.cz> <D4C76825A6780047854A11E93CDE84D02F7767@SAUSEXMBP01.amd.com>,<20100702185702.GB29896@kam.mff.cuni.cz>
Thanks!
I am not defending "peeled" flag proposal. Instead, I used the patch to illustrate
the problem.
Anyway, I opened bug 44794 for this problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44794
Have a wonderful weekend.
Changpeng
________________________________________
From: Zdenek Dvorak [rakdver@kam.mff.cuni.cz]
Sent: Friday, July 02, 2010 1:57 PM
To: Fang, Changpeng
Cc: Richard Guenther; Sebastian Pop; Christian Borntraeger; gcc-patches@gcc.gnu.org; uweigand@de.ibm.com
Subject: Re: [Patch for suggestions]: How do we know a loop is the peeled version?
Hi,
>
> >>instead of the "peeled" flag, it might be better to make sure that the latter optimizers know that
> >>the peeled loop does not roll enough (set nb_iterations_upper_bound/nb_iterations_estimate).
>
> The problem is that we don't know exactly how many iterations are peeled.
> For example, in vect_do_peeling_for_alignment:
>
> niters_of_prolog_loop = vect_gen_niters_for_prolog_loop (loop_vinfo, ni_name,
> &wide_prolog_niters);
>
> We could not give a constant estimation of the upper-bound.
surely there is some upper bound on the number of iterations of the loop (if it
is used to ensure alignment, it cannot be more than the value of the alignment
divided by the step of the memory reference?). For nb_iterations_estimate, you do
not even have to be sure you are correct, it just needs to be a reasonable guess.
> Also, any bounds you set will be erased after dce.
So is anything else that you attach to loop structure, at the moment, so this still
is not an argument for having "peeled" flag.
> >>Passing the information from gimple to rtl loop optimizer is a long-standing problem. One possibility is
> >>to keep the information about the loops up-to-date between the optimizers (few years ago, I made
> >>sure that this is possible up to tree->rtl expansion, so making this work again should not be too hard;
> >>handling the expansion and rtl passes might be a little more challenging, but not terribly so).
> >>A less involved solution is to drop some notes in the instruction stream at the end of gimple loop
> >>optimizer, and pick them up in the rtl one,
>
> Could you please give some details.
I recall having a proof-of-concept patch for this; I will try to find it,
Zdenek