llvm-svn: 95239

with a function with a prototype, treat parameters of enumeration type
based on the enumeration type's promotion type.

llvm-svn: 95238

1-argument ExecutionEngine::create(Module*) ambiguous with the signature that
used to be ExecutionEngine::create(ModuleProvider*, defaulted_params).  Fixed
by removing the 1-argument create().  Fixes PR6221.

llvm-svn: 95236

llvm-svn: 95235

llvm-svn: 95232

llvm-svn: 95231

ever existed. :)

llvm-svn: 95230

is what most readers will actually be aiming for.

llvm-svn: 95229

llvm-svn: 95228

output.

llvm-svn: 95227

llvm-svn: 95226

is done with the other html files in doc, to hopefully keep strings like
"Last modified" current.

llvm-svn: 95225

The SRThreshold value makes perfect sense for checking if an entire aggregate
should be promoted to a scalar integer, but it is not so good for splitting
an aggregate into its separate elements.  A struct may contain a large embedded
array along with some scalar fields that would benefit from being split apart
by SROA.  Even if the total aggregate size is large, it may still be good to
perform SROA.  Thus, the most important piece of this patch is simply moving
the aggregate size comparison vs. SRThreshold so that it guards only the
aggregate promotion.

We have also been checking the number of elements to decide if an aggregate
should be split up.  The limit of "SRThreshold/4" seemed rather arbitrary,
and I don't think it's very useful to derive this limit from SRThreshold
anyway.  I've collected some data showing that the current default limit of
32 (since SRThreshold defaults to 128) is a reasonable cutoff for struct
types.  One thing suggested by the data is that distinguishing between structs
and arrays might be useful.  There are (obviously) a lot more large arrays
than large structs (as measured by the number of elements and not the total
size -- a large array inside a struct still counts as a single element given
the way we do SROA right now).  Out of 8377 arrays where we successfully
performed SROA while compiling a large set of benchmarks, only 16 of them had
more than 8 elements.  And, for those 16 arrays, it's not at all clear that
SROA was actually beneficial.  So, to offset the compile time cost of
investigating more large structs for SROA, the patch lowers the limit on array
elements to 8.

This fixes Apple Radar 7563690.

llvm-svn: 95224

Revert the new reference binding code; I came up with a way simpler solution for the reference binding bug that is preventing self-hosting.

llvm-svn: 95223

First pass at adding GC support for GNU runtime.  GC ivar maps not yet constructed, GC flag not set.

Please don't try using this yet - the runtime support is still very immature and your code will almost certainly crash if you do.  

llvm-svn: 95222

llvm-svn: 95221

prevent a crash on templates when looking for an existing declaration of the
predefined global operators. This fixes PR5918.

Added an easy test case for the overload handling, but testing the crash is
a bit trickier. Created a new test that can use multiple runs with a define to
trigger which test case is used so we can test this type of issue.

llvm-svn: 95220

reference template arguments. Adds test cases for the cv-quals of reference
arguments.

llvm-svn: 95217

that is in an anonymous namespace, give that function or variable
internal linkage.

This change models an oddity of the C++ standard, where names declared
in an anonymous namespace have external linkage but, because anonymous
namespace are really "uniquely-named" namespaces, the names cannot be
referenced from other translation units. That means that they have
external linkage for semantic analysis, but the only sensible
implementation for code generation is to give them internal
linkage. We now model this notion via the UniqueExternalLinkage
linkage type. There are several changes here:

  - Extended NamedDecl::getLinkage() to produce UniqueExternalLinkage
    when the declaration is in an anonymous namespace.
  - Added Type::getLinkage() to determine the linkage of a type, which
    is defined as the minimum linkage of the types (when we're dealing
    with a compound type that is not a struct/class/union).
  - Extended NamedDecl::getLinkage() to consider the linkage of the
    template arguments and template parameters of function template
    specializations and class template specializations.
  - Taught code generation to rely on NamedDecl::getLinkage() when
    determining the linkage of variables and functions, also
    considering the linkage of the types of those variables and
    functions (C++ only). Map UniqueExternalLinkage to internal
    linkage, taking out the explicit checks for
    isInAnonymousNamespace().

This fixes much of PR5792, which, as discovered by Anders Carlsson, is
actually the reason behind the pass-manager assertion that causes the
majority of clang-on-clang regression test failures. With this fix,
Clang-built-Clang+LLVM passes 88% of its regression tests (up from
67%). The specific numbers are:

LLVM:
  Expected Passes    : 4006
  Expected Failures  : 32
  Unsupported Tests  : 40
  Unexpected Failures: 736

Clang:
  Expected Passes    : 1903
  Expected Failures  : 14
  Unexpected Failures: 75

Overall:
  Expected Passes    : 5909
  Expected Failures  : 46
  Unsupported Tests  : 40
  Unexpected Failures: 811

Still to do:
  - Improve testing
  - Check whether we should allow the presence of types with
  InternalLinkage (in addition to UniqueExternalLinkage) given
  variables/functions internal linkage in C++, as mentioned in
  PR5792. 
  - Determine how expensive the getLinkage() calls are in practice;
  consider caching the result in NamedDecl.
  - Assess the feasibility of Chris's idea in comment #1 of PR5792.

llvm-svn: 95216

llvm-svn: 95215

llvm-svn: 95214

llvm-svn: 95213

llvm-svn: 95212

initializer. Grrr....

llvm-svn: 95211

llvm-svn: 95209

llvm-svn: 95208

so that llvm-mc -show-encoding prints like this:

	hlt                                                 ## encoding: [0xf4]

instead of like this:

	hlt
                     # encoding: [0xf4]

llvm-svn: 95207

instead of textually.

llvm-svn: 95206

of const ones.  non-const ones aren't very useful, because you can't
even, say, emit them.

llvm-svn: 95205

llvm-svn: 95203

add -filetype=null for performance testing and remove -filetype=dynlib,
which isn't planned to be implemented.

llvm-svn: 95202

llvm-svn: 95201

RegionStoreManager::InvalidateRegions() by adjusting the worklist to
iterate over BindingKeys instead of MemRegions.  We also only need to
do the actual invalidation work on base regions, and for non-base
regions just blow away their bindings.

llvm-svn: 95200

Implement Doug's suggestion. Eliminate the Stmts pointer from CXXTryStmt and instead allocate the statements after the object.

llvm-svn: 95199

llvm-svn: 95198

instructions on a single line.  Also made it a
bit more forgiving when it reports errors.

llvm-svn: 95197

as undefined.  Fixes an assertion in APFloat::toString noticed by Dale.

llvm-svn: 95196

Allow all types of callee's to be tail called. But avoid automatic tailcall if the callee is a result of bitcast to avoid losing necessary zext / sext etc.

llvm-svn: 95195

 - Requires backend support, which only exists for i386--darwin currently.

No 'as' required:
--
ddunbar@ozzy:tmp$ cat t.c
int main() { return 42; }
ddunbar@ozzy:tmp$ clang -m32 -integrated-as t.c


ddunbar@ozzy:tmp$ ./a.out; echo $?
42
ddunbar@ozzy:tmp$
--

The random extra whitespace is how you know its working! :)

llvm-svn: 95194

not build a subregion map and instead do a single scan of the store.
This is done by building "region clusters" that represent the
collection of regions that have the same base region.  Invalidating
any region in a cluster means that they all should get invalidated.

This change brought out a point that Zhongxing mentioned to me
offline: the flattened memory binding has issues distinguishing
between direct and default bindings.  For example, setting the default
value for an entire struct is the same as binding to the first
element.  To address this problem, I moved the binding "tag" (Direct
or Default) from BindingVal to BdingKey (and removed BindingVal
entirely).  This requires us to do double lookups in some cases; and
there is still much more cleanup that can be done.

This change produced a noticeable speedup when analyzing sqlite3 (a
reduction of 4% in running time).

llvm-svn: 95193