On Mon, Jun 11, 2012 at 5:38 PM, William J. Schmidt <wschm...@linux.vnet.ibm.com> wrote: > > > 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.
Well. At the moment the cost model is purely "local" in that the target receives no context about the cost it has to return for (part of) a vectorized operation. In fact the vectorizer already creates multiple instructions (and thus calls to the cost target hook) for a single scalar statement in some cases. There are two ways to increase the context the target can look at - invent more kinds of "statements" we pass to the cost model hook, and thus arrive at a point where for each group of stmts the vectorizer emits and that possibly has a more efficient target implementation we have a different statement kind (only for the cost model, we continue to generate multiple GIMPLE stmts). The other way is to give the target the ability to see context, thus relation of the (sub-)statements the vectorizer asks the target to compute costs for. I've run into the situation where there was missing context on x86, too (but I forgot the specific case), and that's where I came up with the general idea. Of course both work, but for your kind of heuristic only looking at context works. In the scheme I suggested the fini_cost hook would be able to do the counting (as would a simple counter - I don't believe that this would not work - you do counting, too, after all, simply make the fini hook able to reject the vectorization). If powerpc is issue-limited then you have the additional issue that you have no idea of the amount of address calculations involved (as IVOPTs only runs afterwards). Not sure if those would fit for the intermediate work. Thanks, Richard. > Thanks, > Bill > >> >> Thanks, David >> >
