[llvm-bugs] [Bug 34854] New: GVN removes a call to malloc

via llvm-bugs llvm-bugs at lists.llvm.org
Thu Oct 5 17:47:49 PDT 2017


            Bug ID: 34854
           Summary: GVN removes a call to malloc
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: jlerouge at apple.com
                CC: llvm-bugs at lists.llvm.org

On windows, on the following C code:

C:\> cat malloc.c
__declspec(restrict) __declspec(noalias) void *malloc(unsigned long long);
void foo(void*, void*);

void *my_malloc(unsigned size) {
        return malloc(size);

int main(int argc, char **argv) {
        unsigned size = 1024 * argc;
        void *p = my_malloc(size);
        void *q = my_malloc(size);
        foo(p, q);
        return argc;

C:\> clang -S -emit-llvm -O0 -o - malloc.c | opt -functionattrs -gvn | llvm-dis
| less
  %call = call i8* @my_malloc(i32 %mul)
  store i8* %call, i8** %p, align 8
  store i8* %call, i8** %q, align 8
  call void @foo(i8* %call, i8* %call)
  ret i32 %argc

Basically, one of the calls to my_malloc is removed.

The malloc declaration is based on what it was with VS 2013 (it seems to have
changed in VS2015 and after), and also from the MSDN web page:


> malloc is marked __declspec(noalias) and __declspec(restrict); this means that the function is guaranteed not to modify > global variables, and that the pointer returned is not aliased. For more information, see noalias and restrict.

I went back in time, the behavior changed on r247167 (was ok before, broken

Author: Chandler Carruth <chandlerc at gmail.com>
Date:   Wed Sep 9 17:55:00 2015 +0000

    [PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible
    with the new pass manager, and no longer relying on analysis groups.

    This builds essentially a ground-up new AA infrastructure stack for
    LLVM. The core ideas are the same that are used throughout the new pass
    manager: type erased polymorphism and direct composition. The design is
    as follows:

    - FunctionAAResults is a type-erasing alias analysis results aggregation
      interface to walk a single query across a range of results from
      different alias analyses. Currently this is function-specific as we
      always assume that aliasing queries are *within* a function.

    - AAResultBase is a CRTP utility providing stub implementations of
      various parts of the alias analysis result concept, notably in several
      cases in terms of other more general parts of the interface. This can
      be used to implement only a narrow part of the interface rather than
      the entire interface. This isn't really ideal, this logic should be
      hoisted into FunctionAAResults as currently it will cause
      a significant amount of redundant work, but it faithfully models the
      behavior of the prior infrastructure.

    - All the alias analysis passes are ported to be wrapper passes for the
      legacy PM and new-style analysis passes for the new PM with a shared
      result object. In some cases (most notably CFL), this is an extremely
      naive approach that we should revisit when we can specialize for the
      new pass manager.

    - BasicAA has been restructured to reflect that it is much more
      fundamentally a function analysis because it uses dominator trees and
      loop info that need to be constructed for each function.

    All of the references to getting alias analysis results have been
    updated to use the new aggregation interface. All the preservation and
    other pass management code has been updated accordingly.

    The way the FunctionAAResultsWrapperPass works is to detect the
    available alias analyses when run, and add them to the results object.
    This means that we should be able to continue to respect when various
    passes are added to the pipeline, for example adding CFL or adding TBAA
    passes should just cause their results to be available and to get folded
    into this. The exception to this rule is BasicAA which really needs to
    be a function pass due to using dominator trees and loop info. As
    a consequence, the FunctionAAResultsWrapperPass directly depends on
    BasicAA and always includes it in the aggregation.

    This has significant implications for preserving analyses. Generally,
    most passes shouldn't bother preserving FunctionAAResultsWrapperPass
    because rebuilding the results just updates the set of known AA passes.
    The exception to this rule are LoopPass instances which need to preserve
    all the function analyses that the loop pass manager will end up
    needing. This means preserving both BasicAAWrapperPass and the
    aggregating FunctionAAResultsWrapperPass.

    Now, when preserving an alias analysis, you do so by directly preserving
    that analysis. This is only necessary for non-immutable-pass-provided
    alias analyses though, and there are only three of interest: BasicAA,
    GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is
    preserved when needed because it (like DominatorTree and LoopInfo) is
    marked as a CFG-only pass. I've expanded GlobalsAA into the preserved
    set everywhere we previously were preserving all of AliasAnalysis, and
    I've added SCEVAA in the intersection of that with where we preserve
    SCEV itself.

    One significant challenge to all of this is that the CGSCC passes were
    actually using the alias analysis implementations by taking advantage of
    a pretty amazing set of loop holes in the old pass manager's analysis
    management code which allowed analysis groups to slide through in many
    cases. Moving away from analysis groups makes this problem much more
    obvious. To fix it, I've leveraged the flexibility the design of the new
    PM components provides to just directly construct the relevant alias
    analyses for the relevant functions in the IPO passes that need them.
    This is a bit hacky, but should go away with the new pass manager, and
    is already in many ways cleaner than the prior state.

    Another significant challenge is that various facilities of the old
    alias analysis infrastructure just don't fit any more. The most
    significant of these is the alias analysis 'counter' pass. That pass
    relied on the ability to snoop on AA queries at different points in the
    analysis group chain. Instead, I'm planning to build printing
    functionality directly into the aggregation layer. I've not included
    that in this patch merely to keep it smaller.

    Note that all of this needs a nearly complete rewrite of the AA
    documentation. I'm planning to do that, but I'd like to make sure the
    new design settles, and to flesh out a bit more of what it looks like in
    the new pass manager first.

    Differential Revision: http://reviews.llvm.org/D12080

    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247167

You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20171006/cab376b7/attachment-0001.html>

More information about the llvm-bugs mailing list