Delete all of the CodeGenInstructions from CodeGenTarget destructor.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200906 91177308-0d34-0410-b5e6-96231b3b80d8
A memcpy out of an fresh alloca is a no-op, delete it. Patch by Patrick Walton!


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200907 91177308-0d34-0410-b5e6-96231b3b80d8
[asan] introduce two functions that will allow implementations of C++ garbage colection to work with asan's fake stack

git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@200908 91177308-0d34-0410-b5e6-96231b3b80d8
check-clang: Introduce the feature "utf8-capable-terminal".

clang/test/FixIt/fixit-unicode-with-utf8-output.c has begun complained since LLVM r200885.
Although it is changes for StringRef, it brought LLVM_ON_WIN32 to Support/Locale.cpp.

Before r200885, LLVM_ON_WIN32 was undefined in Locale.cpp!

FIXME: We should consider i18n on win32.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200909 91177308-0d34-0410-b5e6-96231b3b80d8
[asan] fix testing on Mac

git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@200910 91177308-0d34-0410-b5e6-96231b3b80d8
This small change reduces compile time for small programs on targets that have
large register files. The omission of Queries.clear() is perfectly safe because
LiveIntervalUnion::Query doesn't contain any data that needs freeing and
because LiveRegMatrix::runOnFunction happens to reset the OwningArrayPtr
holding Queries every time it is run, so there's no need to zero out the
queries either. Not having to do this for very large numbers of physregs
is a noticeable constant cost reduction in compilation of small programs.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200913 91177308-0d34-0410-b5e6-96231b3b80d8
tsan: improve error message for Go



git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@200914 91177308-0d34-0410-b5e6-96231b3b80d8
tsan: remove unused functions



git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@200915 91177308-0d34-0410-b5e6-96231b3b80d8
tsan: simplify Go build script
we don't use assembly files



git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@200916 91177308-0d34-0410-b5e6-96231b3b80d8
The following patch' purpose is to reduce compile time for compilation of small
programs on targets with large register files. The root of the compile time
overhead was in the use of llvm::SmallVector to hold PhysRegEntries, which
resulted in slow-down from calling llvm::SmallVector::assign(N, 0). In contrast
std::vector uses the faster __platform_bzero to zero out primitive buffers when
assign is called, while SmallVector uses an iterator.

The fix for this was simply to replace the SmallVector with a dynamically
allocated buffer and to initialize or reinitialize the buffer based on the
total registers that the target architecture requires. The changes support
cases where a pass manager may be reused for different targets, and note that
the PhysRegEntries is allocated using calloc mainly for good for, and also to
quite tools like Valgrind (see comments for more info on this).

There is an rdar to track the fact that SmallVector doesn't have platform
specific speedup optimizations inside of it for things like this, and I'll
create a bugzilla entry at some point soon as well.

TL;DR: This fix replaces the expensive llvm::SmallVector<unsigned
char>::assign(N, 0) with a call to calloc for N bytes which is much faster
because SmallVector's assign uses iterators.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200917 91177308-0d34-0410-b5e6-96231b3b80d8
X86: deduplicate V[SZ]EXT_MOVL and V[SZ]EXT nodes

I believe VZEXT_MOVL means "zero all vector elements except the first" (and
should have identical input & output types) whereas VZEXT means "zero extend
each element of a vector (discarding higher elements if necessary)".

For example:
    (v4i32 (vzext (v16i8 ...)))

should zero extend the low 4 bytes of the incoming vector to 32-bits,
discarding higher bytes.

However, somewhere in the past, these two concepts had become confused, even
leading to a nonsensical VSEXT_MOVL.

This re-merges the nodes where appropriate (all VSEXT_MOVL -> VSEXT, VZEXT_MOVL
-> VZEXT when it's an actual extension).

rdar://problem/15981990

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200918 91177308-0d34-0410-b5e6-96231b3b80d8
Yet another patch to reduce compile time for small programs:

The aim in this patch is to reduce work that VirtRegRewriter needs to do when
telling MachineRegisterInfo which physregs are in use. Up until now
VirtRegRewriter::rewrite has been doing rewriting and populating def info and
then proceeding to set whether a physreg is used based this info for every
physreg that the target provides. This can be expensive when a target has an
unusually high number of supported physregs, and is a noticeable chunk of
compile time for small programs on such targets.

So to reduce compile time, this patch simply adds the use of a SparseSet to the
rewrite function that is used to flag each physreg that is encountered in a
MachineFunction. Afterward, rather than iterating over the set of all physregs
for a given target to set the physregs used in MachineRegisterInfo, the new way
is to iterate over the set of physregs that were actually encountered and set
in the SparseSet. This improves compile time because the existing rewrite
function was iterating over all MachineOperands already, and because the
iterations afterward to setPhysRegUsed is reduced by use of the SparseSet data.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200919 91177308-0d34-0410-b5e6-96231b3b80d8
MS ABI: Tweak pointer-to-member mangling/inheritance model selection

Properly determine the inheritance model when dealing with nullptr:
- If a nullptr template argument is being checked against
  pointer-to-member parameter, nail down an inheritance model.
  N.B. We will chose an inheritance model even if we won't ultimately
  choose the template to instantiate!  Cooky, right?
- Null pointer-to-datamembers have a virtual base table offset of -1,
  not zero. Previously, we chose an offset of 0.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200920 91177308-0d34-0410-b5e6-96231b3b80d8
MS ABI: Handle indirect field decls in template args

Properly support fields that come from anonymous unions and structs
when used as template arguments for pointer to data member params.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200921 91177308-0d34-0410-b5e6-96231b3b80d8
[TSan] Don't flush all file streams on program shutdown to avoid deadlocks on file stream locks.
This should fix https://code.google.com/p/thread-sanitizer/issues/detail?id=47.


git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@200922 91177308-0d34-0410-b5e6-96231b3b80d8
[TSan] Add a regression test for https://code.google.com/p/thread-sanitizer/issues/detail?id=47



git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@200923 91177308-0d34-0410-b5e6-96231b3b80d8
[sanitizer] Intercept getresuid and getresgid.

git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@200925 91177308-0d34-0410-b5e6-96231b3b80d8
[sanitizer] Intercept getifaddrs().

git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@200926 91177308-0d34-0410-b5e6-96231b3b80d8
Add a -suppress-warnings option to bitcode linking.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200927 91177308-0d34-0410-b5e6-96231b3b80d8
X86: add costs for 64-bit vector ext/trunc & rebalance

The most important part of this is probably adding any cost at all for
operations like zext <8 x i8> to <8 x i32>. Before they were being
recorded as extremely costly (24, I believe) which made LLVM fall back
on a 4-wide vectorisation of a loop.

It also rebalances the values for sext, zext and trunc. Lacking any
other sane metric that might work across CPU microarchitectures I went
for instructions. This seems to be in reasonable accord with the rest
of the table (sitofp, ...) though no doubt at least one value is
sub-optimal for some bizarre reason.

Finally, separate AVX and AVX2 values are provided where appropriate.
The CodeGen is quite different in many cases.

rdar://problem/15981990

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200928 91177308-0d34-0410-b5e6-96231b3b80d8