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: "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 13:40:12 -0500
- Subject: RE: [Patch for suggestions]: How do we know a loop is the peeled version?
- References: <D4C76825A6780047854A11E93CDE84D02F7763@SAUSEXMBP01.amd.com>,<20100701193818.GB13423@kam.mff.cuni.cz>
>>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.
Also, any bounds you set will be erased after dce.
>>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.