This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [Patch for suggestions]: How do we know a loop is the peeled version?


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]