Skip to content
  1. Feb 18, 2012
  2. Feb 17, 2012
    • Richard Smith's avatar
      Don't emit optimization-specific intrinsic at -O0. · 132bea96
      Richard Smith authored
      llvm-svn: 150838
      132bea96
    • Sebastian Redl's avatar
      Basic code generation support for std::initializer_list. · c83ed824
      Sebastian Redl authored
      We now generate temporary arrays to back std::initializer_list objects
      initialized with braces. The initializer_list is then made to point at
      the array. We support both ptr+size and start+end forms, although
      the latter is untested.
      
      Array lifetime is correct for temporary std::initializer_lists (e.g.
      call arguments) and local variables. It is untested for new expressions
      and member initializers.
      
      Things left to do:
      Massively increase the amount of testing. I need to write tests for
      start+end init lists, temporary objects created as a side effect of
      initializing init list objects, new expressions, member initialization,
      creation of temporary objects (e.g. std::vector) for initializer lists,
      and probably more.
      Get lifetime "right" for member initializers and new expressions. Not
      that either are very useful.
      Implement list-initialization of array new expressions.
      
      llvm-svn: 150803
      c83ed824
    • Richard Smith's avatar
      The clang half of r150794: after the construction of a global or static const · 08a51446
      Richard Smith authored
      variable ends, if the variable has a trivial destructor and no mutable
      subobjects then emit an llvm.invariant.start call for it. globalopt knows to
      make the variable const when evaluating this.
      
      llvm-svn: 150798
      08a51446
    • Eric Christopher's avatar
      Index "12" holds the vtable, not "9". · 2939e6e1
      Eric Christopher authored
      Fixes lots of gdb testsuite failures.
      
      llvm-svn: 150797
      2939e6e1
    • Richard Smith's avatar
      Bug fix: do not emit static const local variables with mutable members · e070fd2a
      Richard Smith authored
      as constants.
      
      Refactor and simplify all the separate checks for whether a type can be
      emitted as a constant.
      
      llvm-svn: 150793
      e070fd2a
    • Richard Smith's avatar
      When performing IRGen on a global, emit it as a constant if: · ae819500
      Richard Smith authored
       1) It has a const-qualified type, and
       2) It has no mutable members, and
       3) It has no dynamic initialization, and
       4) It has trivial destruction.
      Remove the unnecessary requirement that the type be POD. This allows us to
      mark all constexpr objects with no mutable members as 'constant'.
      
      llvm-svn: 150792
      ae819500
    • John McCall's avatar
      Whether an argument is required (in contrast with being an · a729c62b
      John McCall authored
      optional argument passed through the variadic ellipsis)
      potentially affects how we need to lower it.  Propagate
      this information down to the various getFunctionInfo(...)
      overloads on CodeGenTypes.  Furthermore, rename those
      overloads to clarify their distinct purposes, and make
      sure we're calling the right one in the right place.
      This has a nice side-effect of making it easier to construct
      a function type, since the 'variadic' bit is no longer
      separable.
      
      This shouldn't really change anything for our existing
      platforms, with one minor exception --- we should now call
      variadic ObjC methods with the ... in the "right place"
      (see the test case), which I guess matters for anyone
      running GNUStep on MIPS.  Mostly it's just a substantial
      clean-up.
      
      llvm-svn: 150788
      a729c62b
    • Douglas Gregor's avatar
      Rework the Sema/AST/IRgen dance for the lambda closure type's · 355efbb2
      Douglas Gregor authored
      conversion to function pointer. Rather than having IRgen synthesize
      the body of this function, we instead introduce a static member
      function "__invoke" with the same signature as the lambda's
      operator() in the AST. Sema then generates a body for the conversion
      to function pointer which simply returns the address of __invoke. This
      approach makes it easier to evaluate a call to the conversion function
      as a constant, makes the linkage of the __invoke function follow the
      normal rules for member functions, and may make life easier down the
      road if we ever want to constexpr'ify some of lambdas.
      
      Note that IR generation is responsible for filling in the body of
      __invoke (Sema just adds a dummy body), because the body can't
      generally be expressed in C++.
      
      Eli, please review!
      
      llvm-svn: 150783
      355efbb2
  3. Feb 16, 2012
  4. Feb 15, 2012
    • John McCall's avatar
      Split reinterpret_casts of member pointers out from CK_BitCast; this · c62bb391
      John McCall authored
      is general goodness because representations of member pointers are
      not always equivalent across member pointer types on all ABIs
      (even though this isn't really standard-endorsed).
      
      Take advantage of the new information to teach IR-generation how
      to do these reinterprets in constant initializers.  Make sure this
      works when intermingled with hierarchy conversions (although
      this is not part of our motivating use case).  Doing this in the
      constant-evaluator would probably have been better, but that would
      require a *lot* of extra structure in the representation of
      constant member pointers:  you'd really have to track an arbitrary
      chain of hierarchy conversions and reinterpretations in order to
      get this right.  Ultimately, this seems less complex.  I also
      wasn't quite sure how to extend the constant evaluator to handle
      foldings that we don't actually want to treat as extended
      constant expressions.
      
      llvm-svn: 150551
      c62bb391
  5. Feb 14, 2012
  6. Feb 13, 2012
  7. Feb 12, 2012
    • Sebastian Redl's avatar
      Represent C++ direct initializers as ParenListExprs before semantic analysis · a935179a
      Sebastian Redl authored
      instead of having a special-purpose function.
      
      - ActOnCXXDirectInitializer, which was mostly duplication of
        AddInitializerToDecl (leading e.g. to PR10620, which Eli fixed a few days
        ago), is dropped completely.
      - MultiInitializer, which was an ugly hack I added, is dropped again.
      - We now have the infrastructure in place to distinguish between
        int x = {1};
        int x({1});
        int x{1};
      -- VarDecl now has getInitStyle(), which indicates which of the above was used.
      -- CXXConstructExpr now has a flag to indicate that it represents list-
         initialization, although this is not yet used.
      - InstantiateInitializer was renamed to SubstInitializer and simplified.
      - ActOnParenOrParenListExpr has been replaced by ActOnParenListExpr, which
        always produces a ParenListExpr. Placed that so far failed to convert that
        back to a ParenExpr containing comma operators have been fixed. I'm pretty
        sure I could have made a crashing test case before this.
      
      The end result is a (I hope) considerably cleaner design of initializers.
      More importantly, the fact that I can now distinguish between the various
      initialization kinds means that I can get the tricky generalized initializer
      test cases Johannes Schaub supplied to work. (This is not yet done.)
      
      This commit passed self-host, with the resulting compiler passing the tests. I
      hope it doesn't break more complicated code. It's a pretty big change, but one
      that I feel is necessary.
      
      llvm-svn: 150318
      a935179a
  8. Feb 11, 2012
  9. Feb 10, 2012
  10. Feb 09, 2012
Loading