[llvm] r245394 - [BasicAA] Revert r221876 because it can produce incorrect aliasing

Hal Finkel via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 26 06:06:07 PDT 2015


----- Original Message -----
> From: "Nicholas White" <n.j.white at gmail.com>
> To: "Michael Zolotukhin" <mzolotukhin at apple.com>
> Cc: "Quentin Colombet" <qcolombet at apple.com>, llvm-commits at lists.llvm.org, "Hal Finkel" <hfinkel at anl.gov>
> Sent: Wednesday, August 26, 2015 2:53:00 AM
> Subject: Re: [llvm] r245394 - [BasicAA] Revert r221876 because it can produce incorrect aliasing
> 
> Sure - http://reviews.llvm.org/D11847 is the most recent version of
> my
> Sext / Zext handling fixes, and has all the edge cases I've found to
> date. It was reverted above due to a bug in it, which I've tracked
> down to the below. %arrayidx3 and %ra are MayAlias in 3.6.1 but
> NoAlias in my most recent patch.
> 
> define void @benchmark_heapsort(i32 %n, double* nocapture %ra) {
>   %shr = ashr i32 %n, 1
>   %add = add nsw i32 %shr, 1
>   %arrayidx3 = getelementptr inbounds double, double* %ra, i64 1
>   ret void
> }
> 
> Also, is there an easy way of measuring code coverage of an llvm-lit
> run? Given the number of reversions of this patch I think there are
> large coverage gaps, as each iteration has passed all the BasicAA
> unit
> tests :(

Overall coverage from the entire set of regression tests is not bad (http://llvm.org/reports/coverage/lib/Analysis/BasicAliasAnalysis.cpp.gcov.html), but coverage itself is only a small part of the story. Some tests are imprecise, and it is really the various combinations of control flow paths that is the problem.

 -Hal

> 
> Thanks -
> 
> Nick
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory


More information about the llvm-commits mailing list