<div dir="ltr"><div>So after checking the emitted bitcode in the LTO-link step, I found that the method wcsncat already had NoAlias relation with the destination buffer. I had assumed that the !tbaa metadata was module-wide and compared the load/store aliases of method wcsncat and its caller, main.<br><br>Dumped out LLVM bitcode at different steps:<br><br>test1.c.ll: // test case compiled with -flto and linked against the static lib<br>main: !179<br><br>wchar.cpp.ll: // compiled with -flto that is a part of the static lib <br>wcsncat: !362<br><br>lto.ll // bitcode emitted by LTO link<br>main: !20057<br>wcsncat: !20871 // these metadata tells us that they have a NoAlias relation<br><br></div><div>I have a few questions at this point:<br></div><div>1) Is the !tbaa metadata module-wide as in, effective across methods? If not, is inliner suppose to resolve the aliasing of parms/args during inlining?<br></div><div>2) If 1)'s first Q is true and second false, should the gold linker be fixing alias relations? (if true, possibly a gold bug?)<br><br></div><div>Thanks in advance,<br></div><div>Kevin Choi<br></div><div>Intel WOS<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 21 July 2016 at 15:18, Kevin Choi <span dir="ltr"><<a href="mailto:code.kchoi@gmail.com" target="_blank">code.kchoi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Does anyone know how LLVM encodes aliasing on a call? I'm looking at the code in GVN and it seems like it's pulling TBAA metadata as below.<br><br>(ImmutableCallSite*)CS.getInstruction()->getMetadata(LLVMContext::MD_tbaa))<br><br></div>but I do not see !tbaa attached to the call instruction, only !dbg. This is bitcode from LTO link step and I see that LTO pass manager uses both TypeAA and BasicAA. <br><br></div>Any input is appreciated,<br></div>-Kevin<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 20 July 2016 at 16:58, Kevin Choi <span dir="ltr"><<a href="mailto:code.kchoi@gmail.com" target="_blank">code.kchoi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>I think I've narrowed it to a failure point:<br></div>I am seeing that after<br>[0x1a5b080] %35 = call i16* @PAL_wcsncat(i16* %7, i16* %33, i64 %34), !dbg !20064<br><br></div>is inlined into main, the alias of load and the preceding store no longer are aliased. I verified this via inserting modulePrinterPass right after inliningPass.<br></div><br></div>I am wondering if this is because pointer aliasing is incorrectly set up on call to PAL_wcsncat or something is wrong in the inliner. I will see if I can pull the pointer aliases on the callsite.<span><font color="#888888"><br><br></font></span></div><span><font color="#888888">-Kevin<br></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 20 July 2016 at 14:44, Kevin Choi <span dir="ltr"><<a href="mailto:code.kchoi@gmail.com" target="_blank">code.kchoi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>before inlining<br>all 20005<br><br>after inlining<br> somewhere here changed made it NoAlias<br>after Global Variable Optimizer<br> 20014<br>20373 20255<br>20372 20254<br><br><br>before GVN <br> 19993<br>20011 19991<br>20010 20030<br><br></div>It appears that TBAA metadata certainly changed after inlining and subsequent passes. I have attached the .bc file. I think I will try to dump out more TBAA metadata between passes. The method in interest is @main.<div><div><br><div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 20 July 2016 at 11:32, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Wed, Jul 20, 2016 at 11:24 AM, Kevin Choi <span dir="ltr"><<a href="mailto:code.kchoi@gmail.com" target="_blank">code.kchoi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Thanks for quick reply Daniel,<br><br></div><div>I tried to make a simple C testcase, but could not reproduce the same condition with output from Clang. </div></div></blockquote><div><br></div></span><div>even if you have a .ll file you can share, that would be helpful.</div><span><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I suppose I could modify the C code to make it look similar with TBAA's; I may be able to provide this by eod.<span><br><br>> <span>store %ptr above the load. <br><br></span></span></div><div><span>My mistake; I was referring to the store $lcssa in bb2. Looking at the C source code, it should definitely alias with %dest. I will try and see if I can find out why it thinks there is no local dependence.<br></span></div></div></blockquote><div> </div></span><div>Yes, i would start by seeing why the getdependency call is returning no dep :)</div><div><br>At a glance from your file, the load and that store are tagged with different TBAA tags.</div><div>THat does not necessarily mean they don't alias, i'd have to see the TBAA tree to say for sure.</div><div>The TBAA rule is that a tag aliases all of it's descendants and ancestors in the tree.</div><div><br></div><div>So if the tree look like this:<br><br></div><div>!something</div><div> / \</div><div><span style="font-size:12.8px">!20010 !20030</span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">It will say no alias</span></div><div><span style="font-size:12.8px">but if it looks like</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">!something</span></div><div><span style="font-size:12.8px"> |</span></div><div><span style="font-size:12.8px">!20010</span></div><div><span style="font-size:12.8px"> |</span></div><div><span style="font-size:12.8px">!20030</span></div><div><br></div><div>TBAA will say they alias (something else may still say no-alias for other reasons, of course)</div><div><div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span><br></span></div><div><span>Thanks,<br></span></div><div><span>Kevin<br></span></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 20 July 2016 at 11:06, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Wed, Jul 20, 2016 at 9:56 AM, Kevin Choi via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div>Hello to whom this may concern,<br><br></div>Versioned this as I saw identical title before. I'm compiling a clang project where I'm seeing GVN mess up and replace a load with a wrong def value.</div></div></div></div></div></div></div></div></blockquote><div><br></div></span><div><br>Do you have a c testcase or a .ll file i can actually compile?<br> <br></div><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div> I am using LLVM-3.5, but the problem has been observed upto 3.8.<br>To illustrate the problem,<br><br></div><div>define i32 @main<br></div><a href="http://scalar.ph" target="_blank">scalar.ph</a>:<br></div> <initialize [80 x i16] %dest><br>...<br></div><div>preheader:<br></div><div>%index=0<br></div><div>br test, loop1, bb2<br></div>loop1:<br></div> ... write to %dest in increasing index // ptr-based while loop<br></div><div> %ptr++;<br></div> br test, loop1, bb2<br></div><div>bb2:<br></div><div> %lcssa = phi [%ptr, loop1], [%ptr, preheader]<br> store i16 0, i16* %lcssa !dbg !20094 !tbaa 20030 // write null byte at end<br></div><div> %76 = getelementptr inbounds [80 x i16]* %dest, i64 0, i64 7, !dbg !20095 // load addr of null byte (7th index)<br> %77 = load i16* %76, align 2, !dbg !20095, !tbaa !20010<br> %78 = icmp eq i16 %77, 0, !dbg !20095<br> br i1 %78, label %80, label %79, !dbg !20095<br><br></div><div>GVN calls processNonLocalLoad() on "%77 = load..." and replaces it with init value from <a href="http://scalar.ph" target="_blank">scalar.ph</a>.<br><br></div></div></div></blockquote><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>bb2:<br>%lcssa = phi [%ptr, loop1], [%ptr, preheader]<br>store i16 0, i16* %lcssa, !dbg !20094, !tbaa !20030<br>%76 = getelementptr inbounds [80 x i16]* %dest, i64 0, i64 7, !dbg !20095<br>br i1 icmp eq (i16 trunc (i128 lshr (i128 bitcast (<8 x i16> <i16 120, i16 120, i16 120, i16 120, i16 120, i16 120, i16 120, i16 120> to i128), i128 96) to i16), i16 0), label %78, label %77, !dbg !20095 // simplifies to "icmp eq (i16 120, i16 0) --> false"<br><br></div><div>I first suspected problem might be TBAA; invoking clang with -fno-strict-aliasing makes the test pass (similarly, opt with -basicaa does not make GVN transform the load). When I look at the C/C++ source code, I cannot find any type-based aliasing violations from eyeballing.<br></div></div></div></blockquote><div><br></div></div></div><div>Can you excerpt the actual source code? </div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div><div>I started looking at the aliasing and landed at getNonLocalPointerDepFromBB(), in which the worklist algorithm to find MemDep reported the result from the init block, ignoring all the kills after it. I did see one of the parm was SkipFirstBlock and this appears to ignore the store %ptr above the load. Is there a reason why it skips first block?</div></div></div></blockquote><div><br></div><div><br></div></span><div>Yes. It is looking for *non-local* dependences. The block it should skip is bb2, not loop1.</div><div>There is another call for local dependences. If you ask for local dependences, then non-local ones, as GVN does, there is no point in having it go and look at the local ones again :)</div><div><br></div><div>Look at how GVN calls this:</div><div><div><div>MemDepResult Dep = MD->getDependency(L);</div><div><br></div><div> // If it is defined in another block, try harder.</div><div> if (Dep.isNonLocal())</div><div> return processNonLocalLoad(L);</div></div></div><div><br></div><div>(IE get local dependence, if there is none, go looking at non-local dependences).</div><div><br></div><div><br></div><div>The list of non-local dependences it includes should definitely include the one from block "loop1", and if it is ignoring it, it is most likely thinks it does not alias for some reason.</div><div><br></div></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>