llvm-svn: 295288

This patch removes NeedsCopyOrPltAddr and instead add two variables,
NeedsCopy and NeedsPltAddr. This uses one more bit in Symbol class,
but the actual size doesn't increase because we had unused bits.
This should improve code readability.

llvm-svn: 295287

llvm-svn: 295286

libunwind depends on C++ library headers. When building libunwind
as part of LLVM and libc++ is available, use its headers.

Differential Revision: https://reviews.llvm.org/D29997

llvm-svn: 295285

Recommit r293585 that was reverted in r293611 with new fixes.  The previous
issue was determined to be an overly aggressive AST visitor from forward
declared objects.  The visitor will now only deeply visit certain Decl's and
only do a shallow information extraction from all other Decl's.

When objects are imported for modules, there is a chance that a name collision
will cause an ODR violation.  Previously, only a small number of such
violations were detected.  This patch provides a stronger check based on
AST nodes.

The information needed to uniquely identify an object is taken from the AST and
put into a one-dimensional byte stream.  This stream is then hashed to give
a value to represent the object, which is stored with the other object data
in the module.

When modules are loaded, and Decl's are merged, the hash values of the two
Decl's are compared.  Only Decl's with matched hash values will be merged.
Mismatch hashes will generate a module error, and if possible, point to the
first difference between the two objects.

The transform from AST to byte stream is a modified depth first algorithm.
Due to references between some AST nodes, a pure depth first algorithm could
generate loops.  For Stmt nodes, a straight depth first processing occurs.
For Type and Decl nodes, they are replaced with an index number and only on
first visit will these nodes be processed.  As an optimization, boolean
values are saved and stored together in reverse order at the end of the
byte stream to lower the ammount of data that needs to be hashed.

Compile time impact was measured at 1.5-2.0% during module building, and
negligible during builds without module building.

Differential Revision: https://reviews.llvm.org/D21675

llvm-svn: 295284

llvm-svn: 295283

This is slightly inefficient than the previous code, but that is really
negligible as this function is usually called at most only a few times.

llvm-svn: 295282

llvm-svn: 295281

llvm-svn: 295280

Enable evaluation of captures within constexpr lambdas by using a strategy similar to that used in CodeGen:
  - when starting evaluation of a lambda's call operator, create a map from VarDecl's to a closure's FieldDecls
  - every time a VarDecl (or '*this) that represents a capture is encountered while evaluating the expression via the expression evaluator (specifically the LValueEvaluator) in ExprConstant.cpp - it is replaced by the corresponding FieldDecl LValue (an Lvalue-to-Rvalue conversion on this LValue representation then determines the right rvalue when needed).

Thanks to Richard Smith and Hubert Tong for their review and feedback!

https://reviews.llvm.org/D29748

llvm-svn: 295279

Previously, space in a BSS section for copy relocations are reserved
in a special way. We directly manipulated size of the BSS section.
r294577 changed the way of doing it. Now, we create an instance of
CopyRelSection (which is a synthetic input section) for each copy
relocation.

This patch removes the remains of the old way and add CopyRelSections
to BSS sections using `addSections` function, which is the usual
way to add an input section to an output section.

llvm-svn: 295278

This appears to be the only template argument deduction context where we were
missing this check. Surprisingly, other implementations also appear to miss
the check in this case; it may turn out that important code is relying on
the widespread non-conformance here, in which case we'll need to reconsider.

llvm-svn: 295277

llvm-svn: 295276

llvm-svn: 295273

Reviewers: eugenis

Subscribers: llvm-commits, kubamracek

Differential Revision: https://reviews.llvm.org/D30013

llvm-svn: 295272

effects was passed as an expression to assert() calls.  If lldb is
built without asserts, the expression was eliminated and we lost
the side effects -- these methods stopped working.  

<rdar://problem/30342959> 

llvm-svn: 295271

llvm-svn: 295270

Update test uses with expansion in terms of new intrinsics.

llvm-svn: 295269

llvm-svn: 295268

llvm-svn: 295267

After r264564, we allowed direct-list-initialization of an enum from an
integral value in C++1z mode, so long as that value can convert to the
enum's underlying type.

In this kind of initialization, we need a lvalue-to-rvalue conversion
for the initializer value if it is not a rvalue. This lets us accept the
following code:

  enum class A : unsigned {};
  A foo(unsigned x) { return A{x}; }

Differential Revision: https://reviews.llvm.org/D29723

llvm-svn: 295266

llvm-svn: 295265

[c++1z] Diagnose non-deducible template parameters in deduction guide templates, per [temp.param]p11.

llvm-svn: 295264

In the target dependent code we already always return a int64_t. In
the target independent code we carefully use uintX_t, which has the
same result given 2 complement rules.

This just simplifies the code to use int64_t everywhere.

llvm-svn: 295263

This reverts r294348, which removed support for conditional tail calls
due to the PR above. It fixes the PR by marking live registers as
implicitly used and defined by the now predicated tailcall. This is
similar to how IfConversion predicates instructions.

Differential Revision: https://reviews.llvm.org/D29856

llvm-svn: 295262

Summary:
Add in #ifdef to exclude cpu_model_test on non-X86 and  *vfp_test on ARM targets without VFP support.

This is consistent with other target-specific tests that print "Skipped" if not supported.

Reviewers: rengolin, compnerd, asbirlea

Reviewed By: compnerd

Subscribers: llvm-commits, aemerson

Differential Revision: https://reviews.llvm.org/D29882

llvm-svn: 295261

Differential Revision: https://reviews.llvm.org/D30008

llvm-svn: 295260

llvm-svn: 295259

Destructor references are not modelled explicitly in the AST. This adds
checks for destructor calls due to variable definitions and temporaries.

If a dllimport function references a non-dllimport destructor, it must
not be emitted available_externally, as the referenced destructor might
live across the DLL boundary and isn't exported.

llvm-svn: 295258

The function is used to check whether a type is a class with
non-dllimport destructor. It needs to look through typedefs and array
types.

llvm-svn: 295257

llvm-svn: 295256

Uses a Custom implementation because the slot sizes being a multiple of the
pointer size isn't really universal, even for the architectures that do have a
simple "void *" va_list.

llvm-svn: 295255

Since (say) i128 and [16 x i8] map to the same type in generic MIR, we also
need to attach the required alignment info.

llvm-svn: 295254

Fixes PR 31921

Summary:
Predicateinfo requires an ugly workaround to try to avoid literal
struct types due to the intrinsic mangling not being implemented.
This workaround actually does not work in all cases (you can hit the
assert by bootstrapping with -print-predicateinfo), and can't be made
to work without DFS'ing the type (IE copying getMangledStr and using a
version that detects if it would crash).

Rather than do that, i just implemented the mangling.  It seems
simple, since they are unified structurally.

Looking at the overloaded-mangling testcase we have, it actually turns
out the gc intrinsics will *also* crash if you try to use a literal
struct.  Thus, the testcase added fails before this patch, and works
after, without needing to resort to predicateinfo.

Reviewers: chandlerc, davide

Subscribers: llvm-commits, sanjoy

Differential Revision: https://reviews.llvm.org/D29925

llvm-svn: 295253

Two functions that differ only in their enable_if attributes are
considered overloads, so we should check for those when we're trying to
figure out if two functions are mergeable.

We need to do the same thing for pass_object_size, as well. Looks like
that'll be a bit less trivial, since we sometimes do these merging
checks before we have pass_object_size attributes available (see the
merge checks in ASTDeclReader::VisitFunctionDecl that happen before we
read parameters, and merge checks in calls to ReadDeclAs<>()).

llvm-svn: 295252

Differential Revision: https://reviews.llvm.org/D29742

llvm-svn: 295251

llvm-svn: 295248

llvm-svn: 295247

llvm-svn: 295246

llvm-svn: 295245