on 2020/2/11 上午5:29, Segher Boessenkool wrote: > Hi! > > On Mon, Feb 10, 2020 at 02:17:04PM +0800, Kewen.Lin wrote: >> on 2020/1/20 下午8:33, Segher Boessenkool wrote: >>> On Thu, Jan 16, 2020 at 05:36:52PM +0800, Kewen.Lin wrote: >>>> As we discussed in the thread >>>> https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00196.html >>>> Original: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00104.html, >>>> I'm working to teach IVOPTs to consider D-form group access during >>>> unrolling. >>>> The difference on D-form and other forms during unrolling is we can put the >>>> stride into displacement field to avoid additional step increment. eg: >>> >>> <snip> >>> >>>> Imagining that if the loop get unrolled by 8 times, then 3 step updates >>>> with >>>> D-form vs. 8 step updates with X-form. Here we only need to check stride >>>> meet D-form field requirement, since if OFF doesn't meet, we can construct >>>> baseA' with baseA + OFF. >>> >>> So why doesn't the existing code do this already? Why does it make all >>> the extra induction variables? Is the existing cost model bad, are our >>> target costs bad, or something like that? >>> >> >> I think the main cause is IVOPTs runs before RTL unroll, when it's >> determining >> the IV sets, it can only take the normal step cost into account, since its >> input isn't unrolled yet. After unrolling, the x-form indexing register has >> to >> play with more UF-1 times update, but we can probably hide them in d-form >> displacement field. The way I proposed here is to adjust IV cost with >> additional cost_step according to estimated unroll. It doesn't introduce new >> IV cand but can affect the final optimal set. > > Yes, we should decide how often we want to unroll things somewhere before > ivopts already, and just use that info here.
Agreed! If some passes are interested on this unroll factor estimation, we can move backward there if it's before IVOPTs. As patch 1/4, once it's set, the later pass can just reuse that info. As Richard B. suggested, we can even skip the later RTL unroll factor determination. > > Or are there advantage to doing it *in* ivopts? It sounds like doing > it there is probably expensive, but maybe not, and we need to do similar > analysis there anyway. > Good question. I didn't consider that, the reason putting here is we need this information in IVOPTs for some cases. :) BR, Kewen
