[llvm-dev] Can someone give me some pointer on alias analysis ?
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Sat Dec 26 09:32:52 PST 2015
On 12/26/2015 02:17 AM, Amaury SECHET via llvm-dev wrote:
> I'm trying to fix that bug: https://llvm.org/bugs/show_bug.cgi?id=20049
> It turns out this is the kind of optimization that I really need, as
> when it isn't done, all kind of other optimizations opportunities down
> the road are not realized as they are not exposed.
> I have no idea where to start digging for this. I assume there is some
> kind of interaction between memory dependency and alias analysis that
> is overly conservative. Can someone gives me some infos on how the 2
> interact together ? What is the code that is supposed to remove these
> kind of loads ?
First, it looks like you're using an older version of LLVM (the load
syntax has changed). That's definitely not recommended since it will
greatly limit your choices when encountering an issue like this.
Second, the aliasing problem has to do with the effects of the
"allocmemory" callsite on a memory location associated with an earlier
alloca. There's nothing that prevents your allocmemory function from
writing to global state. You have to teach the alias analysis that an
unescaped noalias pointer can't alias the global state allocmemory might
access. Slightly surprised we don't get this today, but oh well. Take
a look at the isNonEscapingLocalObject predicate in BasicAA. Then look
at "getModRefInfo(ImmutableCallSite CS, const MemoryLocation &Loc)".
Double check to make sure this is the one that MDA actually calls.
Third, you might want to take a look the new
inaccessiblememonlyattribute. Depending on how you're modelling your
allocation, this might help resolve the aliasing problem in different
way. However, be aware that this is *very* new. In particular, I
triggered an optimizer bug by adding the new attribute to your
particular example. :(
Fourth, have you considered implementing a simple escape analysis pass?
I notice that the store-load forwarding would just fall out once you
removed the last allocation. I believe the fixed point would then
become a function which returns the constant answer and does nothing else.
Fifth, some pointers on debugging this yourself. GVN (which is the one
which does complicated *-load forwarding) calls MDA
(MemoryDepedenceAnalysis). Using the appropriate -debug-only options
will likely get you to the right area. You can also consider using the
MemDepPrinter pass to bypass GVN. I don't know of a way to issue raw AA
queries for testing. That would be useful, but I don't know that we
Hope that helps.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev