This patch adds on to the exploitation added by https://reviews.llvm.org/D33510.
This now catches build vector nodes where the inputs are coming from sign
extended vector extract elements where the indices used by the vector extract
are not correct. We can still use the new hardware instructions by adding a
shuffle to move the elements to the correct indices. I introduced a new PPCISD
node here because adding a vector_shuffle and changing the elements of the
vector_extracts was getting undone by another DAG combine.

Commit on behalf of Zaara Syeda (syzaara@ca.ibm.com)
Differential Revision: https://reviews.llvm.org/D34009

llvm-svn: 307169

llvm-svn: 307168

llvm-svn: 307167

Make it usable by any class derived (even indirectly) from
LoadedObjectInfo by allowing a custom base class to be specified and
perfect forwarding to the ctor.

llvm-svn: 307166

llvm-svn: 307165

llvm-svn: 307164

Polly did not use PPCG's live range reordering feature. Teach
PPCGCodeGeneration to use this.

Documentation on this is sparse, so much of the code is conservative.

We currently kill all phi nodes in a Scop by appending them to the
must_kill map we pass to PPCG. I do not have a proof of correctness,
but it seems to be intuitively correct.

We also do not handle `array_order`, which, quoting PPCG, is:
PPCG/gpu.h: "Order dependences on non-scalars."
It seems to consist of RAW dependences between arrays. We need to
pass this information for more complex privatization cases.

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

llvm-svn: 307163

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

llvm-svn: 307162

llvm-svn: 307161

Summary:
On older android targets, we needed a dlopen rename workaround to get
"process load" working. Since API 26 this is not required as the targets
have a proper libdl so with the function names one would expect.

To make this work I've had to remove the const qualifier from the
GetLibdlFunctionDeclarations function (as now the declarations can
depend on the connected target). Since I was already modifying the
prototype (and the lower levels were already converted to StringRef) I
took the oportunity to convert this function as well.

llvm-svn: 307160

[globalisel][tablegen] Finish fixing compile-time regressions by merging the matcher and emitter state machines.

Summary:
Also, made a few minor tweaks to shave off a little more cumulative memory consumption:
* All rules share a single NewMIs instead of constructing their own. Only one
  will end up using it.
* Use MIs.resize(1) instead of MIs.clear();MIs.push_back(I) and prevent
  GIM_RecordInsn from changing MIs[0].

Depends on D33764

Reviewers: rovka, vitalybuka, ab, t.p.northover, qcolombet, aditya_nandakumar

Reviewed By: ab

Subscribers: kristof.beyls, igorb, llvm-commits

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

llvm-svn: 307159

llvm-svn: 307158

This adds exact flags to AShr/LShr flags where we can statically
prove it is valid using the range of induction variables. This
allows further optimisations to remove extra loads.

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

llvm-svn: 307157

This moves determination of the ISA revision from the CPU name to
one single place, removing a bunch of duplicated code.  It also
makes the supported ISA revisions available as feature strings.

No functional change.

llvm-svn: 307156

Several integer multiply/divide instructions require use of a
register pair as input and output.  This patch moves setting
up the input register pair from C++ code to TableGen, simplifying
the whole process and making it more easily extensible.

No functional change.

llvm-svn: 307155

Fixes a couple of whitespace errors, re-sorts the vector floating-point
instructions to make them more easily extensible, and adds a missing
pseudo instruction.

No functional change.

llvm-svn: 307154

llvm-svn: 307153

llvm-svn: 307152

llvm-svn: 307151

Summary:
This is like the LLVM_TOOLS_INSTALL_DIR option, but for the utils
that are installed when the LLVM_INSTALL_UTILS.  This option
defaults to 'bin' to remain consistent with the current behavior, but
distros may want to install these to libexec/llvm.

Reviewers: beanz

Reviewed By: beanz

Subscribers: llvm-commits, mgorny

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

llvm-svn: 307150

We used to have a helper that replaced an instruction with a libcall.
That turns out to be too aggressive, since sometimes we need to replace
the instruction with at least two libcalls. Therefore, change our
existing helper to only create the libcall and leave the instruction
removal as a separate step. Also rename the helper accordingly.

llvm-svn: 307149

This implements suggesting other mnemonics when an invalid one is specified,
for example:

$ echo "adXd r1,r2,#3" | llvm-mc -triple arm
<stdin>:1:1: error: invalid instruction, did you mean: add, qadd?
adXd r1,r2,#3
^

The implementation is target agnostic, but as a first step I have added it only
to the ARM backend; so the ARM backend is a good example if someone wants to
enable this too for another target.

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

llvm-svn: 307148

llvm-svn: 307147

[globalisel][tablegen] Fix the misuse of STATISTICS() on release builds (like r307088) after r307133.

r307133 brought back a couple instances of the same mistake that was already
fixed by r307088. Fixed it again.

Using NumPatternEmitted as a unique id for the tables is not valid on release
builds since the counters don't count in that case.

llvm-svn: 307146

Extract functionality for determining if the target uses AEABI.

llvm-svn: 307145

llvm-svn: 307144

llvm-svn: 307143

llvm-svn: 307142

This isn't used anywhere yet, but I need it for a future commit.

llvm-svn: 307141

Summary:
Otherwise the fallback path fails with an assertion on x86_64 targets,
when "x86_fp80" is encountered.

Reviewers: t.p.northover, zvi, guyblank

Reviewed By: zvi

Subscribers: rovka, kristof.beyls, llvm-commits

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

llvm-svn: 307140

Add a helper for building simple binary ops like add, mul, sub, and.
This can be used in the future for quickly adding support for or, xor.

llvm-svn: 307139

llvm-svn: 307138

Attempt to fix Windows buildbots From 307131 Replaced return {ET, false};
with return std::make_pair(ET, false);

llvm-svn: 307137

This change permits there to be more than one thunk to be associated with
a symbol. For interworking thunks we only require one thunk, but range
extension thunks may require more than one.

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

llvm-svn: 307136

This patch seems to cause failures of test MathExtras.SaturatingMultiply on
multiple buildbots. Reverting until the reason of that is clarified.

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

llvm-svn: 307135

Fixes https://bugs.llvm.org/show_bug.cgi?id=33574

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

llvm-svn: 307134

Summary:
This further improves the compile-time regressions that will be caused by a
re-commit of r303259.

Also added included preliminary work in preparation for the multi-insn emitter
since I needed to change the relevant part of the API for this patch anyway.

Depends on D33758

Reviewers: rovka, vitalybuka, ab, t.p.northover, qcolombet, aditya_nandakumar

Reviewed By: ab

Subscribers: kristof.beyls, igorb, llvm-commits

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

llvm-svn: 307133

On ARM the interworking thunks are only produced for branch instructions
that can't be changed into a blx instruction so only Thumb callers would
call Thumb thunks and only ARM callers would call ARM thunks. With range
extension thunks branch and link instructions may need a Thunk. These
instructions can be rewritten as a blx and can use either ARM or Thumb
thunks.

We introduce an isCompatibleWith() function so that a caller can check if
an existing Thunk is compatible before reusing it.

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

llvm-svn: 307132

The allocateHeaders() function is called at the end of assignAddresses(), it
decides whether the ELF header and program header table can be allocated to
a PT_LOAD program header. As the function alters state, it prevents
assignAddresses() from being called multiple times.

This change splits out the call to allocateHeaders() from assignAddresses()
this will permit assignAddresses() to be called while processing range
extension thunks without trying to allocateHeaders().

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

llvm-svn: 307131

Reviewers: alexfh, aaron.ballman

Reviewed By: alexfh

Subscribers: JDevlieghere, Eugene.Zelenko, xazax.hun, cfe-commits

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

llvm-svn: 307130