On Mon, 2012-06-11 at 11:09 -0400, David Edelsohn wrote: > On Mon, Jun 11, 2012 at 10:55 AM, Richard Guenther <rguent...@suse.de> wrote: > > > Well, they are at least magic numbers and heuristics that apply > > generally and not only to the single issue in sphinx. And in > > fact how it works for sphinx _is_ magic. > > > >> Second, I suggest that you need to rephrase "I can make you" and > >> re-send your reply. > > > > Sorry for my bad english. Consider it meaning that I'd rather have > > you think about a more proper solution. That's what patch review > > is about after all, no? Sometimes a complete re-write (which gets > > more difficult which each of the patches "enhancing" the not ideal > > current state) is the best thing to do. > > Richard, > > The values of the heuristics may be "magic", but Bill believes the > heuristics are testing the important characteristics. The heuristics > themselves are controlled by hooks, so the target can set the correct > values for their own requirements. > > The concern is that a general cost infrastructure is too general. > And, based on history, all ports simply will copy the boilerplate from > the first implementation. It also may cause more problems because the > target has relatively little information to be able to judge > heuristics at that point in the middle-end. If the targets start to > get too "cute" or too complicated, it may cause more problems or more > confusion about why more complicated heuristics are not effective and > not producing the expected results. > > I worry about creating another machine dependent reorg catch-all pass. > > Maybe an incremental pre- and/or post- cost hook would be more > effective. I will let Bill comment.
Thanks David, I can see both sides of this, and it's hard to judge the future from where I stand. My belief is that the number of heuristics targets will implement will be fairly limited, since judgments about cycle-level costs are not accurately predictable during the middle end. All we can do is come up with a few things that seem to make sense. Doing too much in the back end seems impractical. The interesting question to me is whether cost model heuristics are general enough to be reusable. What I saw in this case was what I considered to be a somewhat target-neutral problem: overwhelming those assets of the processor that implement vectorization. It seemed reasonable to provide hooks for others to use the idea if they encounter similar issues. If reusing the heuristic is useful, then having to copy the logic from one target to another isn't the best approach. If nobody else will ever use it, then embedding it in the back end is reasonable. Unfortunately my crystal ball has been on the fritz for several decades, so I can't tell you for sure which is right... Richard, my biggest question is whether you think other targets are likely to take advantage of a more general back-end interface, or whether this will end up just being a PowerPC wart. If you know of ways this will be useful for i386, that would be helpful to know. Perhaps this requires your crystal ball as well; not sure how well yours works... If we look at just this one issue in isolation, then changing all the code in the vectorizer that calculates inside/outside loop costs and moving it to targetm seems more invasive than adding the few hooks. But if this will really be a useful feature for the community as a whole I am certainly willing to tackle it. Thanks, Bill > > Thanks, David >
