[NVPTX] Fix i1 kernel parameters and global variables.  ABI rules say we need to use .u8 for i1 parameters for kernels.

llvm-svn: 182253

We need this to avoid races when ASan and LSan are used together.

llvm-svn: 182252

llvm-svn: 182251

llvm-svn: 182250

Leak checking functionality which will be shared between
LSan/ASan/MSan.

llvm-svn: 182249

llvm-svn: 182248

llvm-svn: 182247

llvm-svn: 182246

This is the first in a series of CLs implementing LeakSanitizer.
http://clang.llvm.org/docs/LeakSanitizer.html

llvm-svn: 182245

Also fix wrong alignment maths and an outdated comment

llvm-svn: 182238

Introduction:
In case when stack alignment is 8 and GPRs parameter part size is not N*8:
we add padding to GPRs part, so part's last byte must be recovered at
address K*8-1.
We need to do it, since remained (stack) part of parameter starts from
address K*8, and we need to "attach" "GPRs head" without gaps to it:

Stack:
|---- 8 bytes block ----| |---- 8 bytes block ----| |---- 8 bytes...
[ [padding] [GPRs head] ] [ ------ Tail passed via stack  ------ ...

FIX:
Note, once we added padding we need to correct *all* Arg offsets that are going
after padded one. That's why we need this fix: Arg offsets were never corrected
before this patch. See new test-cases included in patch.

We also don't need to insert padding for byval parameters that are stored in GPRs
only. We need pad only last byval parameter and only in case it outsides GPRs
and stack alignment = 8.
Though, stack area, allocated for recovered byval params, must satisfy
"Size mod 8 = 0" restriction.

This patch reduces stack usage for some cases:
We can reduce ArgRegsSaveArea since inner N*4 bytes sized byval params my be
"packed" with alignment 4 in some cases.

llvm-svn: 182237

llvm-svn: 182235

[sanitizer] factor out ByteMap from SizeClassAllocator32 so that it can be later replaced with a more memory-efficient implementation on 64-bit.

llvm-svn: 182234

The export list for this test requires the following symbols to be available:
  JITTest_AvailableExternallyFunction
  JITTest_AvailableExternallyGlobal
The change in r181200 commented them out, which caused the test to fail to
link, at least on Darwin. I have only reverted the change for arm, since I
can't test the other targets and since it sounds like that change was fixing
real problems for those other targets. It should be possible to rearrange the
code to keep those definitions outside the #ifdefs, but that should be done by
someone who can reproduce the problems that r181200 was trying to fix.

llvm-svn: 182233

Revert "Revert "Debug Info: Using declarations/DW_TAG_imported_declaration of variables, types, and functions.""

This reverts commit r181947 (git d2990ce56a16050cac0d7937ec9919ff54c6df62 )

This addresses one of the two issues identified in r181947, ensuring
that types imported via using declarations only result in a declaration
being emitted for the type, not a definition. The second issue (emitting
using declarations that are unused) is hopefully an acceptable increase
as the real fix for this would be a bit difficult (probably at best we
could record which using directives were involved in lookups - but may
not have been the result of the lookup).

This also ensures that DW_TAG_imported_declarations (& directives) are
not emitted in line-tables-only mode as well as ensuring that typedefs
only require/emit declarations (rather than definitions) for referenced
types.

llvm-svn: 182231

so that their names are hidden.

This addresses comments raised by Sean/Rafael.

llvm-svn: 182230

llvm-svn: 182229

llvm-svn: 182228

llvm-svn: 182227

llvm-svn: 182226

The wired physreg doesn't work on tied operands like on MOVXCC.

Add a README note to fix this later.

llvm-svn: 182225

llvm-svn: 182224

This fixes a bootstrapping problem with builds for Apple ARM targets.
Clang had the wrong prototype for __clear_cache with ARM targets.  Rafael
fixed that in clang svn r181784 and r181810, but without those changes,
we can't build this code for ARM because clang reports an error about the
declaration in Memory.inc not matching the builtin declaration. Some of our
buildbots need to use an older compiler that doesn't have the clang fix.
Since __clear_cache is never used here when __APPLE__ is defined, I'm just
conditionalizing the declaration to match that. I also moved the declaration
of sys_icache_invalidate inside the conditional for __APPLE__ while I was at
it.

llvm-svn: 182223

llvm-svn: 182222

Also clean up the arguments to all the MOVCC instructions so the
operands always are (true-val, false-val, cond-code).

llvm-svn: 182221

llvm-svn: 182220

[Sparc] Rearrange integer registers' allocation order so that register allocator will use I and G registers before using L and O registers.

Also, enable registers %g2-%g4 to be used in application and %g5 in 64 bit mode.

llvm-svn: 182219

llvm-svn: 182218

llvm-svn: 182217

llvm-svn: 182216

Other operating systems, including FreeBSD and NetBSD, use long.

llvm-svn: 182215

AArch64 ELF uses .rela relocations so there's no need to actually make
use of the bits we're setting in the destination  However, we should
make sure all bits are cleared properly since multiple runs of
resolveRelocations are possible and these could combine to produce
invalid results if stale versions remain in the code.

llvm-svn: 182214

lli's remote MCJIT code calls setExecutable just prior to running
code. In line with Darwin behaviour this seems to be the place to
invalidate any caches needed so that relocations can take effect
properly.

llvm-svn: 182213

llvm-svn: 182212

llvm-svn: 182211

On 32-bit hosts %p can print garbage when given a uint64_t, we should
use %llx instead. This only affects the output of the debugging text
produced by lli.

llvm-svn: 182209

llvm-svn: 182207

Summary: + improved handling of default style and predefined styles.

Reviewers: djasper, klimek

Reviewed By: klimek

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D813

llvm-svn: 182205

llvm-svn: 182204

imply -fno-math-errno if the user passed -fno-fast-math OR -ffast-math,
regardless of in which order and regardless of the tool chain default.

I've fixed this to follow the logic:

1) If the last dominating flag is -fno-math-errno, -ffast-math, or
   -Ofast, then do not use math-errno.
2) If the last dominating flag is an explicit -fmath-errno, do use
   math-errno.
3) Otherwise, use the toolchain default.

This, for example, allows the flag sequence
'-ffast-math ... -fno-fast-math' with no mention of '-fmath-errno' or
'-fno-math-errno' to preserve the toolchain default. Most notably, this
should prevent users trying to disable fast-math optimizations on Darwin
and BSD platforms from simultaneously enabling (pointless) -fmath-errno.

I've enhanced the tests (after more reorganization) to cover this and
other weird permutations of flags and targets.

llvm-svn: 182203