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: backward threading heuristics tweek


On 08/15/2016 02:06 PM, Jan Hubicka wrote:
So the threaded path lives fully inside loop1: 6->8->9->3->4->6 propagating
that phi_inserted is 0 after the first iteration of the loop.  This looks like
useful loop peeling oppurtunity which does not garble loop structure. So
perhaps threading paths starting and passing loop latch (i.e. peeling) is
sane? Perhaps all paths fully captured in the loop in question are?
Peeling like this has long been a point of contention -- it totally
mucks things up like vectorizing.

The general issue that the threader knows nothing about the
characteristics of the loop -- thus peeling is at this point is
premature and just as likely to hinder performance as improve it.

I'm never been happy with how this aspect of threading vs loop opts
turned out and we have open BZs related to this rats nest of issues.

Ok, then we perhaps just want to silence the testcase?
We might. I'll have to take a closer look though. Which means I have to stop losing time to other things every day ;(

jeff


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