llvm-svn: 260482

llvm-svn: 260481

This test isn't posix specific, but it doesn't pass on Windows and is
XFAILed. I suspect that this test, which is expected to fail, is causing
the hangs I'm seeing on our WinASan builder.  Moving it to Posix seems
to be the cleanest way to avoid running it on Windows.

llvm-svn: 260480

Summary:
We can't do the right thing, since there's no right thing to do, but at
least we can not crash the compiler.

Reviewers: majnemer, rnk

Subscribers: cfe-commits, jhen, tra

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

llvm-svn: 260479

Summary:
Actions don't depend on the toolchain; they get bound to a particular
toolchain via BindArch.

No functional changes.

Reviewers: echristo

Subscribers: cfe-commits

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

llvm-svn: 260478

llvm-svn: 260477

llvm-svn: 260476

It thinks that these functions don't match the function pointer type
that they are passed with:

GCDAProfiling.c(578) : warning C4113: 'void (__cdecl *)()' differs in parameter lists from 'void (__cdecl *)(void)'
GCDAProfiling.c(579) : warning C4113: 'void (__cdecl *)()' differs in parameter lists from 'void (__cdecl *)(void)'
GCDAProfiling.c(580) : warning C4113: 'void (__cdecl *)()' differs in parameter lists from 'void (__cdecl *)(void)'

llvm-svn: 260475

For now, generic virtual registers will not have a register class. We may want
to change that. For instance, if we want to use all the methods from
TargetRegisterInfo with generic virtual registers, we need to either have some
sort of generic register classes that do what we want, or teach those methods
how to deal with nullptr register class.

Although the latter seems easy enough to do, we may still want to differenciate
generic register classes from nullptr to catch cases where nullptr gets
introduced by a bug of some sort.

Anyway, I will file a PR to keep track of that.

llvm-svn: 260474

This is an asan/android test harness change aiming to catch
"adb pull" failures on the buildbot.

llvm-svn: 260473

Something changed the inference of nonnull.

llvm-svn: 260472

llvm-svn: 260471

llvm-svn: 260470

Make sure we split ":" from the end of the global function id (which
is <path>:<function> for local functions) instead of the beginning to
avoid splitting at the wrong place for Windows file paths that contain
a ":".

llvm-svn: 260469

llvm-svn: 260468

llvm-svn: 260467

The current function importer will walk the callgraph, importing
transitively any callee that is below the threshold. This can
lead to import very deep which is costly in compile time and not
necessarily beneficial as most of the inline would happen in
imported function and not necessarilly in user code.

The actual factor has been carefully chosen by flipping a coin ;)
Some tuning need to be done (just at the existing limiting threshold).

Reviewers: tejohnson

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 260466

They don't count for the memory or file size, so this is mostly just a
simplification.

The only noticeable difference should be fewer empty program headers.

llvm-svn: 260465

llvm-svn: 260464

Global constructors and destructors are guaranteed to be called
in the order as they appear in a translation unit. So we don't want
to mess up the order if they have the same priority.

llvm-svn: 260463

There is not reason to pass an array of "char *" to rebuild a set if
the client already has one.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 260462

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 260461

llvm-svn: 260460

llvm-svn: 260459

Summary:
Just like the existing find_as() method, the new insert_as() accepts
an extra parameter which is used as a key to find the bucket in the
map.
When creating a Constant, we want to check the map before actually
creating the object. In this case we have to perform two queries to
the map, and this extra parameter can save recomputing the hash value
for the second query.

Reviewers: dexonsmith, chandlerc

Subscribers: llvm-commits

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 260458

LLVM_BUILD_GLOBAL_ISEL

llvm-svn: 260457

llvm-svn: 260456

Summary: Measured to be more performant when reading bitcode.

Reviewers: rafael, dexonsmith

Subscribers: llvm-commits

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 260455

The Use argument was used to compute the operand number for a fast
path when replacing only one operand. However we always have to go
through all the operands. So the argument number can be recomputed
locally anyway.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 260454

IMHO this makes the code easier to read and should help with linker
scripts.

This is strongly based on D16575. The main differences are:

We record a range of sections, not every section in a program header.

scanHeaders takes case of deciding what goes in every program header,
including PT_GNU_RELRO

We create dummy sections for the start of the file

With this, program header creation has 3 isolated stages:

Map sections to program headers.
Assign addresses to *sections*
Looking at sections find the address and size of each program header.

Thanks to George Rimar for the initial version.

llvm-svn: 260453

short option as an aid to memory.  Like it's w because of the W in throW.

That helps me remember.  If we are going to take these out we should take them
all out.  But I kind of like them.

llvm-svn: 260452

It looks like clang has a couple of test cases which caught the fact LVI was not slightly more precise after 260439.  When looking at the failures, it struck me as wasteful to be querying nullness of a constant via LVI, so instead of tweaking the clang tests, let's just stop querying constants from this source.

llvm-svn: 260451

The patch adds a parameter in annotateValueSite() to control the max number
of records written to the value profile meta data for each value site. The
default is kept as the current value of 3.

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

llvm-svn: 260450

This caused the compiler to fail with "invalid linkage type
for global declaration" (PR26569).

llvm-svn: 260449

Previously we attempted to be smart; if one job failed, we'd run all
jobs that didn't depend on the failing job.

Problem is, this doesn't work well for e.g. CUDA compilation without
-save-temps.  In this case, the device-side and host-side Assemble
actions (which actually are responsible for preprocess, compile,
backend, and assemble, since we're not saving temps) are necessarily
distinct.  So our clever heuristic doesn't help us, and we repeat every
error message once for host and once for each device arch.

The main effect of this change, other than fixing CUDA, is that if you
pass multiple cc files to one instance of clang and you get a compile
error, we'll stop when the first cc1 job fails.

Reviewers: tra, echristo

Subscribers: jhen, cfe-commits

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

llvm-svn: 260448

Previously the code used getActiveBits() to determine the highest set
bit of each APInt first. However doing so requires the same amount of
memory accesses as simply comparing both numbers right away.

Removing all the active bit checks leads to simpler code and is faster
in my benchmark.

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

llvm-svn: 260447

llvm-svn: 260446

We already do this for Objective-C interfaces, but we never handled protocols
because the DWARF didn't represent them.  Nowadays, though, we can import them
from modules, and we have to mark them properly.

<rdar://problem/24193009>

llvm-svn: 260445

llvm-svn: 260444

llvm-svn: 260443