<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><span></span></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><span></span></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><span></span></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><span></span></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>I think this should be a call on TargetTransformInfo (TTI) similar to the instruction costs (TTI is a machine model). Targets can override this with the right value.<br><br>If we add a(nother) machine model we also have to implement the APIs to query it. I don't think we would save complexity here and we add another model to maintain.</div><div><br></div><div>If we want have this in a description fiIe I think we should express in terms of the existing machine sched model. We could for example express this in terms of the existing load and store latencies and then have TTI query it through targetloweringinfo. Though I am not convinced that is necessary.</div><div><br></div><div>Sent from my iPhone<div><br>On Jun 12, 2015, at 3:06 PM, Gerolf Hoflehner <<a href="mailto:ghoflehner@apple.com">ghoflehner@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">+Adam<div class=""><br class=""></div><div class="">I’m seeing more cases where the compiler makes guesses about the processor rather than querying a machine model. Rather than a sophisticated model there could be a basic/lightweight machine description file that can be queried when it is available. In this specific example a formula like 'dependence distance/ width > store2load_fwd_delay' would help conflict modeling. Does that sound like a promising path forward?</div><div class=""><br class=""></div><div class="">Cheers</div><div class="">Gerolf</div><div class=""><br class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 11, 2015, at 10:11 PM, Das, Dibyendu <<a href="mailto:Dibyendu.Das@amd.com" class="">Dibyendu.Das@amd.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><font face="Calibri" size="2" style="font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-size: 11pt;" class=""><div class="">I have been looking into this small test case (Part A) where loop vectorization is disabled due to possible store-load forwarding conflict (Part B). As you can see, due to the presence of dependence distance 2 the loop is vectorizable only for a width of 2. However, the presence of dependence distance 15 (due to y[j-15]) results in store-load forwarding issue as store packet of y[16:17] (iteration j=16) partially overlaps with load packets of y[15:16] (iteration j=30) and y[17:18] (iteration j=32). As conflicts introduce additional delays in the store->load forwarding pipes, this fact is modeled in the method<span class="Apple-converted-space"> </span><font face="Arial Narrow" class="">MemoryDepChecker::couldPreventStoreLoadForward(</font><font face="Arial Narrow" class="">)</font><span class="Apple-converted-space"> </span>in LoopAccessAnalysis.cpp. The function may turn off vectorization in the presence of such conflicts. Looking through the code gives me the feeling that it may be more conservative than desired. The reason being, if the dependence distance is high, the conflicting store may flush out of the store pipe by the time the load is issued. And vectorization may become beneficial.</div><div class=""> </div><div class="">I am seeing some performance improvements when I disable the method above. This is for x86. Hence I am seeking some advice on how to improve the following logic. Can we better model<span class="Apple-converted-space"> </span><font size="1" class=""><span style="font-size: 8pt;" class="">NumCyclesForStoreLoadThroughMemory</span></font><font size="1" class=""><span style="font-size: 8pt;" class=""><span class="Apple-converted-space"> </span></span></font>? This may be way too high ? Or there are other ways to circumvent the basic problem ?</div><div class=""> </div><div class="">-TIA</div><div class="">Dibyendu</div><div class=""> </div><div class="">Part A:</div><div class=""><font size="1" class=""><span style="font-size: 8pt;" class=""> const unsigned NumCyclesForStoreLoadThroughMemory = 8*TypeByteSize; // 512 for the test case shown</span></font></div><div class=""><font size="1" class=""><span style="font-size: 8pt;" class=""> // Maximum vector factor.</span></font></div><div class=""><font size="1" class=""><span style="font-size: 8pt;" class=""> unsigned MaxVFWithoutSLForwardIssues = VectorizerParams::MaxVectorWidth * TypeByteSize; <span class="Apple-converted-space"> </span></span></font></div><div class=""><font size="1" class=""><span style="font-size: 8pt;" class=""> if(MaxSafeDepDistBytes < MaxVFWithoutSLForwardIssues)</span></font></div><div class=""><font size="1" class=""><span style="font-size: 8pt;" class=""> MaxVFWithoutSLForwardIssues = MaxSafeDepDistBytes;</span></font></div><div class=""><font size="1" class=""><span style="font-size: 8pt;" class=""> </span></font></div><div class=""><font size="1" class=""><span style="font-size: 8pt;" class=""> for (unsigned vf = 2*TypeByteSize; vf <= MaxVFWithoutSLForwardIssues; vf *= 2) {</span></font></div><div class=""><font size="1" class=""><span style="font-size: 8pt;" class=""> if (Distance % vf && Distance / vf < NumCyclesForStoreLoadThroughMemory) {</span></font></div><div class=""><font size="1" class=""><span style="font-size: 8pt;" class=""> MaxVFWithoutSLForwardIssues = (vf >>=1);</span></font></div><div class=""><font size="1" class=""><span style="font-size: 8pt;" class=""> break;</span></font></div><div class=""><font size="1" class=""><span style="font-size: 8pt;" class=""> }</span></font></div><div class=""><font size="1" class=""><span style="font-size: 8pt;" class=""> }</span></font></div><div class=""><font size="1" class=""><span style="font-size: 8pt;" class=""> </span></font></div><div class=""><font size="1" class=""><span style="font-size: 8pt;" class=""> if (MaxVFWithoutSLForwardIssues< 2*TypeByteSize) {</span></font></div><div class=""><font size="1" class=""><span style="font-size: 8pt;" class=""> DEBUG(dbgs() << "LAA: Distance " << Distance <<</span></font></div><div class=""><font size="1" class=""><span style="font-size: 8pt;" class=""> " that could cause a store-load forwarding conflict\n");</span></font></div><div class=""><font size="1" class=""><span style="font-size: 8pt;" class=""> return true;</span></font></div><div class=""><font size="1" class=""><span style="font-size: 8pt;" class=""> }</span></font></div><div class="">----------------------------</div><div class=""><font size="2" class=""><span style="font-size: 10pt;" class="">Part B:</span></font></div><div class=""><font size="2" class=""><span style="font-size: 10pt;" class="">typedef unsigned long long uint64;</span></font></div><div class=""><font size="2" class=""><span style="font-size: 10pt;" class=""> </span></font></div><div class=""><font size="2" class=""><span style="font-size: 10pt;" class="">void foo(const unsigned char *m, unsigned int block, uint64 y[80])</span></font></div><div class=""><font size="2" class=""><span style="font-size: 10pt;" class="">{</span></font></div><div class=""><font size="2" class=""><span style="font-size: 10pt;" class=""> const unsigned char *sblock;</span></font></div><div class=""><font size="2" class=""><span style="font-size: 10pt;" class=""> int i, j;</span></font></div><div class=""><font size="2" class=""><span style="font-size: 10pt;" class=""> </span></font></div><div class=""><font size="2" class=""><span style="font-size: 10pt;" class=""> for (i = 0; i < (int) block; i++) {</span></font></div><div class=""><font size="2" class=""><span style="font-size: 10pt;" class=""> sblock = m + (i << 7);</span></font></div><div class=""><font size="2" class=""><span style="font-size: 10pt;" class=""> </span></font></div><div class=""><font size="2" class=""><span style="font-size: 10pt;" class=""> for (j = 16; j < 80; j++) {</span></font></div><div class=""><font size="2" class=""><span style="font-size: 10pt;" class=""> y[j] = y[j - 2] + y[j - 15] ;</span></font></div><div class=""><font size="2" class=""><span style="font-size: 10pt;" class=""> }</span></font></div><div class=""><font size="2" class=""><span style="font-size: 10pt;" class=""> }</span></font></div><div class=""><font size="2" class=""><span style="font-size: 10pt;" class="">}</span></font></div><div class="">Part C:</div><div class=""><snip> from the debug dump during the LoopAccessAnalysis phase:</div><div class=""> </div><div class="">LAA: Checking memory dependencies</div><div class="">LAA: Src Scev: {(8 + %y),+,8}<%for.body3>Sink Scev: {(128 + %y),+,8}<nsw><%for.body3>(Induction step: 1)</div><div class="">LAA: Distance for %3 = load i64, i64* %arrayidx6, align 8 to store i64 %add, i64* %arrayidx8, align 8: 120</div><div class="">LAA: Distance 120 that could cause a store-load forwarding conflict</div><div class=""> </div><div class=""> </div><div class=""> </div><div class=""> </div></span></font><span style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">LLVM Developers mailing list</span><br style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:LLVMdev@cs.uiuc.edu" style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">LLVMdev@cs.uiuc.edu</a><span style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><span class="Apple-converted-space"> </span> </span><a href="http://llvm.cs.uiuc.edu/" style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">http://llvm.cs.uiuc.edu</a><br style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></div></blockquote></div><br class=""></div></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>LLVM Developers mailing list</span><br><span><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a></span><br><span><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></span><br></div></blockquote></div></div></div></div></div></div></body></html>