<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi Geoff,</div><div class=""><br class=""></div><div class="">Yes, we discovered that failure too (this is 473.astar, right?), you could find some discussion in this thread:</div><div class=""><a href="http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150824/295925.html" class="">http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150824/295925.html</a></div><div class=""><br class=""></div><div class="">There is no a clear solution at this point though.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Michael</div><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 27, 2015, at 11:28 AM, Geoff Berry via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" class="">llvm-commits@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi All,<br class=""><br class="">I've tracked down a failure in SPEC2006 to BasicAliasAnalysis, and I believe<br class="">the fix is part of the code touched by the repeated revert/un-revert cycle<br class="">set off by the original change in the subject line above. Specifically, the<br class="">patch that I believe fixes the failure is:<br class=""><br class=""> Value *Result = GetLinearExpression(CastOp, Scale, Offset, Extension,<br class="">DL,<br class=""> Depth + 1, AC, DT);<br class=""> Scale = Scale.zext(OldWidth);<br class="">- Offset = Offset.zext(OldWidth);<br class="">+<br class="">+ // We have to sign-extend even if Extension == EK_ZeroExt as we can't<br class="">+ // decompose a sign extension (i.e. zext(x - 1) != zext(x) - zext(-1)).<br class="">+ Offset = Offset.sext(OldWidth);<br class=""><br class="">Is this a known issue that someone is working to address, or a case of a bad<br class="">series of reverts/un-reverts? Hal, it looks like you introduced this code<br class="">in r221876. Is this bug fix part of the original patch worth checking in<br class="">separately? Quentin, can you comment on whether just this part of the patch<br class="">is okay w.r.t. the failures that caused you to most recently revert it?<br class=""><br class="">Here is a test case that demonstrates the problem. Without this fix,<br class="">basicaa returns NoAlias for the two GEPs, which causes gvn to replace the<br class="">load with undef.<br class=""><br class="">; RUN: opt < %s -basicaa -aa-eval -print-all-alias-modref-info<br class="">-disable-output 2>&1 | FileCheck %s<br class="">target datalayout = "e-m:e-i64:64-i128:128-n32:64-S128"<br class="">target triple = "aarch64--linux-gnu"<br class=""><br class="">declare noalias i8* @malloc(i64)<br class=""><br class="">; CHECK-LABEL: gvnbadundef:<br class="">; CHECK: MustAlias: i8* %idx_minus1_sext_ptr, i8* %%idx_sext_minus1_ptr<br class="">define i8 @gvnbadundef(i8 %val, i64 %size, i32 %idx) {<br class="">entry:<br class=""> %mem = tail call noalias i8* @malloc(i64 %size)<br class=""><br class=""> ; mem[idx-1] = val<br class=""> %idx_minus1 = add nsw i32 %idx, -1<br class=""> %idx_minus1_sext = sext i32 %idx_minus1 to i64<br class=""> %idx_minus1_sext_ptr = getelementptr inbounds i8, i8* %mem, i64<br class="">%idx_minus1_sext<br class=""> store i8 %val, i8* %idx_minus1_sext_ptr, align 1<br class=""><br class=""> ; return mem[idx-1]<br class=""> %idx_sext = sext i32 %idx to i64<br class=""> %idx_sext_minus1 = add nsw i64 %idx_sext, -1<br class=""> %idx_sext_minus1_ptr = getelementptr inbounds i8, i8* %mem, i64<br class="">%idx_sext_minus1<br class=""> %load4 = load i8, i8* %idx_sext_minus1_ptr, align 1<br class=""> ret i8 %load4<br class="">}<br class=""><br class=""><br class="">--<br class="">Geoff Berry<br class="">Employee of Qualcomm Innovation Center, Inc.<br class=""> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux<br class="">Foundation Collaborative Project<br class=""><br class=""><br class="">_______________________________________________<br class="">llvm-commits mailing list<br class=""><a href="mailto:llvm-commits@lists.llvm.org" class="">llvm-commits@lists.llvm.org</a><br class="">https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Dcommits&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=ygVmcuuQ1MUhRUoJm-IgPtgjmvM0byfjlHDg99vufEI&m=QWqSSQ5DxOlduXqFTxx_1fGW9_f8psq0ASbWM7wDRxQ&s=jikhMUF3xFqXCiLQUAuQy0ui_CWe_1TcDb9MQAW6OZs&e= <br class=""></div></div></blockquote></div><br class=""></body></html>