[llvm-dev] LibCallAliasAnalysis class instantiation parameter

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Sat Aug 15 19:31:23 PDT 2015

Hi Chris,

LibCallAliasAnalysis was recently deleted from trunk because it was never really used or supported. We do need a way to reason about errno, but we don't have it yet.

To your particular problem, if you can compile your code with -fno-math-errno (or -ffast-math which implies it), then the sin/cos functions will be marked as readnone and AA will understand that they don't have side effects.


----- Original Message -----
> From: "Chris Chrulski via llvm-dev" <llvm-dev at lists.llvm.org>
> To: llvm-dev at lists.llvm.org
> Sent: Thursday, August 6, 2015 11:04:26 AM
> Subject: Re: [llvm-dev] LibCallAliasAnalysis class instantiation parameter
> Hello,
> [sorry for the duplicate post, attempting to fix the formatting of
> the previous post]
> Can anybody tell me the intent of the LibCallAliasAnalysis class? I
> see that to instantiate it, it requires a class derived from the
> pure virtual class LibCallInfo, but I cannot find any classes in the
> source tree that derive from LibCallInfo. Is this derived class
> intended to be supplied from a compiler front-end, library writer,
> or the llvm backend?
> I was looking at a case similar to the following:
>               #include <math.h>
>      double x[1000], y[1000];
>      double angle;
>      void rotate(int point_count) {
>         int i;
>             for (i=0; i < point_count; i++) {
>                     double tmp_x = x[i];
>              x[i] = tmp_x * cos(angle) - y[i] * sin(angle);
>                     y[i] = y[i] * cos(angle) + tmp_x * sin(angle);
>          }
>      }
> In this case, the queries done by getModRefInfo are unable to avoid
> loading the ‘angle’ variable from memory for each call to sin/cos.
> Based on the comments in LibCallSemantics.h, it appears that
> LibCallAliasAnalysis should be able to handle this case by
> recognizing that sin/cos only affect errno. However, I don’t see any
> way of enabling this analysis without an appropriate derivation of
> LibCallInfo. Does anybody have info related to this?
> Thanks,
> Chris
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org         http://llvm.cs.uiuc.edu
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

More information about the llvm-dev mailing list