The encoding of build attributes is already tested in CodeGen/ARM/build-attributes-encoding.s

llvm-svn: 199393

Fixing a warning that causes the sanitizer build disliked about mixing && and ||. Since this is generated code, the && has been removed from the expression entirely.

llvm-svn: 199392

IIArith -> II_ADD, II_ADDU, II_AND, II_CL[ZO], II_DADDIU, II_DADDU,
  II_DROTR, II_DROTR32, II_DROTRV, II_DSLL, II_DSLL32, II_DSLLV,
  II_DSR[AL], II_DSR[AL]32, II_DSR[AL]V, II_DSUBU, II_LUI, II_MOV[ZFNT],
  II_NOR, II_OR, II_RDHWR, II_ROTR, II_ROTRV, II_SLL, II_SLLV, II_SR[AL],
  II_SR[AL]V, II_SUBU, II_XOR

No functional change since the InstrItinData's have been duplicated.

This is necessary because the classes are shared between all schedulers.

Once this patch series is committed there will be an InstrItinClass for
each mnemonic with minimal grouping. This does increase the size of the
itinerary tables for each MIPS scheduler but we have a few options for dealing
with that later. These options include reducing the number of classes once
we see the best way to simplify them, or by extending tablegen to be able
to compress the table by eliminating duplicates entries, etc.

llvm-svn: 199391

llvm-svn: 199390

This matches the itin class used by the non-microMIPS equivalents of these
instructions.

llvm-svn: 199389

llvm-svn: 199388

Factored some function-like type reasoning out of SemaDeclAttr and onto Decl itself. This allows for more declarative subjects in attribute tablegen where the attribute appertains to something function-like, but not strictly a FunctionDecl.

llvm-svn: 199387

llvm-svn: 199386

llvm-svn: 199385

This change allows to compile sanitizer sources so that *san runtime
will attempt to use libbacktrace and/or libiberty for symbolization
(instead of communicating with llvm-symbolizer).

I've tested this patch by manually defining SANITIZER_LIBBACKTRACE and/or
SANITIZER_CP_DEMANGLE, linking with necessary libraries and verifying that
all tests from ASan test suite work.

Based on patches by Jakub Jelinek!

llvm-svn: 199384

llvm-svn: 199383

Giving the asm attribute some keyword spellings based off of GCC's documentation. No functional changes.

llvm-svn: 199382

[mips] IIImult should have an InstrItinData in the generic scheduler. Used the same one as for IIImul.

Affects:
  DMULT, DMULTu, MADD, MADD_MM, MADDU, MADDU_MM, MSUB, MSUB_MM, MSUBU,
  MSUBU_MM, MULT, MULTu

Does not affect MULT_MM, MULTu_MM since they are currently miscategorised
as IIImul.

llvm-svn: 199381

llvm-svn: 199380

llvm-svn: 199379

Distinguish between attributes explicitly written at the request of the user, and attributes implicitly generated to assist in bookkeeping by the compiler. This is done so by table generating a CreateImplicit method for each attribute.

Additionally, remove the optional nature of the spelling list index when creating attributes. This is supported by table generating a Spelling enumeration when the spellings for an attribute are distinct enough to warrant it.

llvm-svn: 199378

This change adds ASAN_OPTIONS=start_deactivated=1 flag. When present, ASan will
start in "deactivated" mode, with no heap poisoning, no quarantine, no stack
trace gathering, and minimal redzones. All this features come back when
__asan_init is called for the constructor of an instrumented library.

The primary use case for this feature is Android. Code itself is not
Android-specific, and this patch includes a Linux test for it.

llvm-svn: 199377

There are two attempted optimisations in reMaterializeTrivialDef, trying to
avoid promoting the size of a register too much when rematerializing.
Unfortunately, both appear to be flawed. First, we see if the original register
would have worked, but this is inadequate. Consider:

    v1 = SOMETHING (v1 is QQ)
    v2:Q0 = COPY v1:Q1 (v1, v2 are QQ)
    ...
    uses of v2

In this case even though v2 *could* be used directly as the output of
SOMETHING, this would set the wrong bits of the QQ register involved. The
correct rematerialization must be:

    v2:Q0_Q1 = SOMETHING (v2 promoted to QQQ)
    ...
    uses of v2:Q1_Q2

For the second optimisation, if the correct remat is "v2:idx = SOMETHING" then
we can't necessarily expect v2 itself to be valid for SOMETHING, but we do try
to hunt for a class between v1 and v2 that works. Unfortunately, this is also
wrong:

    v1 = SOMETHING (v1 is QQ)
    v2:Q0_Q1 = COPY v1 (v1 is QQ, v2 is QQQ)
    ...
    uses of v2 as a QQQ

The canonical rematerialization here is "v2:Q0_Q1 = SOMETHING". However current
logic would decide that v2 could be a QQ (no interest is taken in later uses).

This patch, therefore, always accepts the widened register class without trying
to be clever. Generally there is no penalty to this (e.g. in the common GR32 <
GR64 case, expanding the width doesn't matter because it's not like you were
going to do anything else with the high bits of a GR32 register). It can
increase register pressure in cases like the ARM VFP regs though (multiple
non-overlapping but equivalent subregisters). This situation can be
spotted by the fact that both source and destination in the
not-quite-coalesced pair have a sub-register index and
rematerialisation is skipped in that situation.

Unfortunately, no in-tree targets actually expose this as far as I can tell
(there are so few isAsCheapAsAMove instructions for it to trigger on) so I've
been unable to produce a test. It was exposed in our ARM64 SPEC tests though,
and I will be adding a test there that we should be able to contribute
soon(TM).

rdar://problem/15775279

llvm-svn: 199376

We would attempt to determine the inheritance relationship between
classes 'A' and 'B' during static_cast if we tried to convert from 'int
A::*' to 'int B::*'.  However, the question "does A derive from B" is
not meaningful when 'A' isn't defined.

Handle this case by requiring that 'A' be defined.

This fixes PR18506.

llvm-svn: 199374

llvm-svn: 199373

flag from clang, and disable zero-base shadow support on all platforms
where it is not the default behavior.

- It is completely unused, as far as we know.
- It is ABI-incompatible with non-zero-base shadow, which means all
objects in a process must be built with the same setting. Failing to
do so results in a segmentation fault at runtime.
- It introduces a backward dependency of compiler-rt on user code,
which is uncommon and complicates testing.

This is the Clang part of a larger change.

llvm-svn: 199372

flag from clang, and disable zero-base shadow support on all platforms
where it is not the default behavior.

- It is completely unused, as far as we know.
- It is ABI-incompatible with non-zero-base shadow, which means all
objects in a process must be built with the same setting. Failing to
do so results in a segmentation fault at runtime.
- It introduces a backward dependency of compiler-rt on user code,
which is uncommon and complicates testing.

This is the LLVM part of a larger change.

llvm-svn: 199371

llvm-svn: 199370

llvm-svn: 199369

So clang-format can now format:

  int c = []()->int { return 2; }();
  int c = []()->vector<int> { return { 2 }; }();

llvm-svn: 199368

Previously we had bodged together some hacks mapping MachO embedded
targets (i.e. mainly ARM v6M and v7M) to the "*-*-darwin-eabi" triple.
This is incorrect in both details (they don't run Darwin and they're
not EABI in any real sense).

This commit appropriates the existing "MachO" environment for the
purpose instead.

llvm-svn: 199367

llvm-svn: 199366

llvm-svn: 199365

Allow x86 mov instructions to/from memory with absolute address to be encoded and disassembled with a segment override prefix. Fixes PR16962.

llvm-svn: 199364

llvm-svn: 199363

llvm-svn: 199362

llvm-svn: 199361

llvm-svn: 199360

llvm-svn: 199359

This patch adds the capability to dump export table contents. An example
output is this:

  Export Table:
   Ordinal      RVA  Name
         5   0x2008  exportfn1
         6   0x2010  exportfn2

By adding this feature to llvm-objdump, we will be able to use it to check
export table contents in LLD's tests. Currently we are doing binary
comparison in the tests, which is fragile and not readable to humans.

llvm-svn: 199358

llvm-svn: 199357

The generation of the native_export_file end up in
several different makefiles. All those makefiles
write the same file, but can be executed concurrently...
and bad things happen!

llvm-svn: 199356

llvm-svn: 199355

Move copying of global initializers below the cloning of functions.

The BlockAddress doesn't have access to the correct basic blocks until the
functions have been cloned. This causes the BlockAddress to point to the old
values. Just wait until the functions have been cloned before copying the
initializers.
PR13163

llvm-svn: 199354

Remove use of OpSize for populating VEX_PP field. A prefix encoding is now used instead. Simplify some other code. No functional changes intended.

llvm-svn: 199353