This is the mail archive of the
mailing list for the GCC project.
Re: [Patch for suggestions]: How do we know a loop is the peeled version?
- From: Zdenek Dvorak <rakdver at kam dot mff dot cuni dot cz>
- To: "Fang, Changpeng" <Changpeng dot Fang at amd dot com>
- 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 20:57:02 +0200
- 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>
> >>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,
> 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,