[LTO] Modify lto.exports to force the sanitizer to rebuilt LTO.exports

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199361 91177308-0d34-0410-b5e6-96231b3b80d8
Revert r199361: Now, the sanitizer got the change

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199362 91177308-0d34-0410-b5e6-96231b3b80d8
Use a slightly smaller hack.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199363 91177308-0d34-0410-b5e6-96231b3b80d8
Allow x86 mov instructions to/from memory with absolute address to be encoded and disassembled with a segment override prefix. Fixes PR16962.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199364 91177308-0d34-0410-b5e6-96231b3b80d8
Copy segment register when optimizing to MOV8ao8/MOV16ao16/MOV32ao32.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199365 91177308-0d34-0410-b5e6-96231b3b80d8
AVX-512: fixed a compare pattern


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199366 91177308-0d34-0410-b5e6-96231b3b80d8
For ARM, fix assertuib failures for some ld/st 3/4 instruction with wirteback.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199369 91177308-0d34-0410-b5e6-96231b3b80d8
[asan] Remove -fsanitize-address-zero-base-shadow command line
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199371 91177308-0d34-0410-b5e6-96231b3b80d8
ReMat: fix overly cavalier attitude to sub-register indices

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199376 91177308-0d34-0410-b5e6-96231b3b80d8
[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.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199381 91177308-0d34-0410-b5e6-96231b3b80d8
[mips] Correct itin class for MULT_MM and MULTu_MM to IIImult.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199389 91177308-0d34-0410-b5e6-96231b3b80d8
[mips][sched] Split IIArith in preparation for the first scheduler targeting a specific MIPS CPU.

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.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199391 91177308-0d34-0410-b5e6-96231b3b80d8
Move the xscale build attribute test to the proper place and remove the old one.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199393 91177308-0d34-0410-b5e6-96231b3b80d8
[mips][sched] Split IILogic into II_AND, II_OR, II_XOR, II_ANDI, II_ORI, II_XORI

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

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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199394 91177308-0d34-0410-b5e6-96231b3b80d8
[mips][sched] Split IIseb into II_SEB and II_SEH

No functional change since there are no InstrItinData's.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199396 91177308-0d34-0410-b5e6-96231b3b80d8
Add an emitRawComment function and use it to simplify some uses of EmitRawText.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199397 91177308-0d34-0410-b5e6-96231b3b80d8
[mips][sched] Put AND, OR, XOR, MOVT_I, and MOVF_I in the same itinerary class as their non-microMIPS counterparts.

No functional change since both classes have the same InstrItinData definition.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199402 91177308-0d34-0410-b5e6-96231b3b80d8
[mips][sched] Removed IIXfer. No instructions use it.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199403 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-symbolizer: make mangled name heuristic apply to all symbols

PR: http://llvm.org/pr18431
Review: http://llvm-reviews.chandlerc.com/D2552


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199404 91177308-0d34-0410-b5e6-96231b3b80d8
Tweak the MCExternalSymbolizer to print references to C string literals
with raw_ostream's write_escaped() method.

For example darwin's otool(1) program that uses the llvm
disassembler now produces disassembly like this:

leaq	0x7b(%rip), %rdi ## literal pool for: "%f\ntoto\n"

and not print the new lines which messes up the output.

rdar://15145300


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