Summary: Help differentiate code and data by parsing DWARF information. This will reduce false positive rates where data is placed in executable sections and is mistakenly parsed as code, resulting in an inflation in the number of indirect CF instructions (and hence an inflation of the number of unprotected).

Also prints the DWARF line data around the region of each indirect CF instruction.

Reviewers: pcc

Subscribers: probinson, llvm-commits, vlad.tsyrklevich, mgorny, aprantl, kcc

Differential Revision: https://reviews.llvm.org/D38654

llvm-svn: 317050

Re-commit: [globalisel][tablegen] Keep track of the insertion point while adding BuildMIAction's. NFC

Multi-instruction emission needs to ensure the the instructions are generated
a depth-first fashion. For example:
(ADDWrr (SUBWrr a, b), c)
needs to emit the SUBWrr before the ADDWrr. However, our walk over
TreePatternNode's is highly context sensitive which makes it difficult to append
BuildMIActions in the order we want. To fix this, we now keep track of the
insertion point as we add actions. This will allow multi-insn emission to insert
BuildMI's in the correct place.

The previous commit failed on the Ubuntu bots using GCC 4.8. These bots lack the
const_iterator forms of insert() and emplace() that were added in C++11. As a
result I've switched the const_iterators to iterators.

llvm-svn: 317049

This formulation might be slightly slower since I eagerly compute the cheap replacements.  If anyone sees this having a compile time impact, let me know and I'll use lazy population instead.

llvm-svn: 317048

Differential Revision: https://reviews.llvm.org/D39271

llvm-svn: 317046

llvm-svn: 317045

Revert r317040: [globalisel][tablegen] Keep track of the insertion point while adding BuildMIAction's. NFC

The same bots fail but I believe I know what the issue is now. These bots are
missing the const_iterator versions of insert/emplace/etc. that were introduced
in C++11.

llvm-svn: 317042

Change the map key from DIFile* to the absolute path string. Computing
the absolute path isn't expensive because we already have a map that
caches the full path keyed on DIFile*.

llvm-svn: 317041

Re-commit: [globalisel][tablegen] Keep track of the insertion point while adding BuildMIAction's. NFC

Multi-instruction emission needs to ensure the the instructions are generated
a depth-first fashion. For example:
 (ADDWrr (SUBWrr a, b), c)
needs to emit the SUBWrr before the ADDWrr. However, our walk over
TreePatternNode's is highly context sensitive which makes it difficult to append
BuildMIActions in the order we want. To fix this, we now keep track of the
insertion point as we add actions. This will allow multi-insn emission to insert
BuildMI's in the correct place.

The previous commit failed on the Ubuntu bots using GCC 4.8. These bots didn't
like a call to emplace(). I've replaced it with insert() to see if it's a quirk
of the C++11 support.

llvm-svn: 317040

Summary:
Apps that benefit:
- alien isolation
- bioshock infinite
- civilization: beyond earth
- company of heroes 2
- dirt showdown
- dota 2
- F1 2015
- grid autosport
- hitman
- legend of grimrock
- serious sam 3: bfe
- shadow warrior
- talos principle
- total war: warhammer
- UE4 demos: effects cave, elemental, sun temple

Reviewers: arsenm, nhaehnle

Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, llvm-commits, t-tye

Differential Revision: https://reviews.llvm.org/D38914

llvm-svn: 317038

llvm-svn: 317037

Revert r317029: [globalisel][tablegen] Keep track of the insertion point while adding BuildMIAction's. NFC

The Linux bots don't seem to like this usage of emplace(). Reverting while I look into it.

llvm-svn: 317033

Revert "[DWARF] Now that Optional is standard layout, put it into an union instead of splatting it."

GCC doesn't like it. This reverts commit r317028.

llvm-svn: 317030

Multi-instruction emission needs to ensure the the instructions are generated
a depth-first fashion. For example:
  (ADDWrr (SUBWrr a, b), c)
needs to emit the SUBWrr before the ADDWrr. However, our walk over
TreePatternNode's is highly context sensitive which makes it difficult to append
BuildMIActions in the order we want. To fix this, we now keep track of the
insertion point as we add actions. This will allow multi-insn emission to insert
BuildMI's in the correct place.

llvm-svn: 317029

No functionality change intended.

llvm-svn: 317028

No functionality change.

llvm-svn: 317027

[globalisel][tablegen] Factor out implicit def/use renderers from createAndImportInstructionRenderer(). NFC

Multi-instruction emission will require that we have separate handling for
the defs between the implicitly created temporaries and the rule outputs.
The former require new temporary vregs while the latter should copy existing
operands. Factor out the implicit def/use renderers to minimize the code
duplication when we implement that.

llvm-svn: 317025

[SimplifyCFG] Use a more generic name for the selects created by SpeculativelyExecuteBB to prevent long names from being created

Currently the selects are created with the names of their inputs concatenated together. It's possible to get cases that chain these selects together resulting in long names due to multiple levels of concatenation. Our internal branch of llvm managed to generate names over 100000 characters in length on a particular test due to an extreme compounding of the names.

This patch changes the name to a generic name that is not dependent on its inputs.

Differential Revision: https://reviews.llvm.org/D39440

llvm-svn: 317024

[SimplifyCFG] Regenerate some test cases using update_test_checks.py to prepare for an upcoming commit. NFC

A future commit will change how some of the value names in the IR are generated which causes these tests to break in their current form. The script generates checks with regular expressions so it should be immune.

llvm-svn: 317023

[globalisel][tablegen] Add infrastructure to potentially allow BuildMIAction to choose a mutatable instruction. NFC

Prepare for multiple instruction emission by allowing BuildMIAction to
search for a suitable matcher that will support mutation.

This patch deliberately neglects to add matchers aside from the root to
preserve NFC. That said, it should be noted that until we support mutations
other than just the opcode the chances of finding a non-root instruction
for which canMutate() is true, is essentially zero. Furthermore in the
presence of multi-instruction emission the chances of finding any
instruction for which canMutate() is true is also zero. Nevertheless, we
can't continue to require that all BuildMIAction's consider the root of the match
to be recyclable due to the risk of recycling it twice in the same rule.

llvm-svn: 317022

These are only testing 64-bit targets so we don't need the regex

llvm-svn: 317021

llvm-svn: 317020

This makes uses of Optional more transparent to the compiler (and
clang-tidy) and generates slightly smaller code.

llvm-svn: 317019

Reviewers: aprantl
llvm-svn: 317018

llvm-svn: 317017

This an intermediate state, the next patch will re-inline the markLoopInvariantPredicate function to reduce code duplication.

llvm-svn: 317016

Previously, we call write(2) for each 32767 byte chunk. That is not
efficient because Linux can handle much larger write requests.
This patch changes the chunk size on Linux to 1 GiB.

This patch also changes the default chunks size to SSIZE_MAX. I think
that doesn't in practice change this function's behavior on any operating
system because SSIZE_MAX on 64-bit machine is unrealistically large,
and writing 2 GiB (SSIZE_MAX on 32-bit) on a 32-bit machine by a single
call of write(2) is also unrealistic, as the userspace is usually
limited to 2 GiB. That said, it is in general a good thing to do because
a write larger than SSIZE_MAX is implementation-defined in POSIX.

Differential Revision: https://reviews.llvm.org/D39444

llvm-svn: 317015

Possibly very slightly slower, but this code is not performance critical and the readability benefit alone is huge.

llvm-svn: 317012

It can't be a register prefix, anyway. This is consistent with the masm
docs on MSDN: https://msdn.microsoft.com/en-us/library/t4ax90d2.aspx

This is a straight-forward extension of our support for "MOD"
implemented in https://reviews.llvm.org/D33876 / r306425

llvm-svn: 317011

Fixes a bunch of assert-on-invalid-bitcode regressions after 315483.
Expected<> calls assertIsChecked() in its dtor, and operator bool() only calls
setChecked() if there's no error. So for functions that don't return an error
itself, the Expected<> version needs explicit code to disarm the error that the
ErrorOr<> code didn't need.

https://reviews.llvm.org/D39437

llvm-svn: 317010

COFF comdats require symbol table entries, which means the comdat leader
cannot have private linkage.

llvm-svn: 317009

Mainly a perf improvements as most combines will have occurred before we lower to these instructions

llvm-svn: 317005

No functionality change intended.

llvm-svn: 317003

This fixes dsymutil/cmdline.test on platforms where the dsymutil binary
has an extension.

llvm-svn: 317001

Summary: The loop invariant add (i+j) is reassoicated, I think the FIXME can be removed, because this is what the test case tries to check (AFAIK). I also changed the test to use FileCheck.

Reviewers: mcrosier, davide

Reviewed By: mcrosier, davide

Subscribers: davide, llvm-commits

Differential Revision: https://reviews.llvm.org/D39424

llvm-svn: 317000

This patch adds the --threads option to dsymutil to process
architectures in parallel. The feature is already present in the version
distributed with Xcode, but was not yet upstreamed.

This is NFC as far as the linking behavior is concerned. As threads are
used automatically, the current tests cover the change in
implementation.

Differential revision: https://reviews.llvm.org/D39355

llvm-svn: 316999

Summary:
Use 64 instead of 32 bits of the module hash as the suffix when renaming
after promotion to reduce the likelihood of a collision (which we
observed in a binary when using 32 bits).

Reviewers: pcc

Subscribers: llvm-commits, inglorion

Differential Revision: https://reviews.llvm.org/D39443

llvm-svn: 316996

If a select instruction tests the returned flag of a cmpxchg instruction and
selects between the returned value of the cmpxchg instruction and its compare
operand, the result of the select will always be equal to its false value.

Differential Revision: https://reviews.llvm.org/D39383

llvm-svn: 316994

Based on similar python tool - utils/shuffle-fuzz.py - this tool extends the ability of it's previous by optionally attaching select instruction to the generated shufflevector instructions.
This was mainly developed to perform exhaustive testing of the X86 AVX512 masked shuffle instructions. But yet it can be used for various other targets.
The general design of the implementation is much modular than the original shuffle_fuzz.py tool, which makes it easier for anyone to extend it further.

Differential Revision: https://reviews.llvm.org/D38031

Change-Id: I0efc2aaa091b61a8a9552311c21cc77916a97111
llvm-svn: 316989

The optimisation remarks for loop unrolling with an unrolled remainder looks something like:

test.c:7:18: remark: completely unrolled loop with 3 iterations [-Rpass=loop-unroll]
            C[i] += A[i*N+j];
                 ^
test.c:6:9: remark: unrolled loop by a factor of 4 with run-time trip count [-Rpass=loop-unroll]
        for(int j = 0; j < N; j++)
        ^
This removes the first of the two messages.

Differential revision: https://reviews.llvm.org/D38725

llvm-svn: 316986

extract subvector of vXi1 from vYi1 is poorly supported by LLVM and most of the time end with an assertion.
This patch fixes this issue by adding new patterns to the TD file.

Reviewers:
1. guyblank
2. igorb
3. zvi
4. ayman
5. craig.topper

Differential Revision: https://reviews.llvm.org/D39292

Change-Id: Ideb4d7e946c8d40cfce2920891f2d89fe64c58f8
llvm-svn: 316981