[CodeGen] Fix inconsistent declaration parameter name

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

[AMDGPU] [AMDGPU] Support a fdot2 pattern.

Summary: Optimize fma((float)S0.x, (float)S1.x fma((float)S0.y, (float)S1.y, z))
                   -> fdot2((v2f16)S0, (v2f16)S1, (float)z)

Author: FarhanaAleen

Reviewed By: rampitec, b-sumner

Subscribers: AMDGPU

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

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

[llvm] Change 2 instances of std::sort to llvm::sort

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

[InstCombine] Fold 'check for [no] signed truncation' pattern

Summary:
[[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]]

As discussed in https://reviews.llvm.org/D49179#1158957 and later,
the IR for 'check for [no] signed truncation' pattern can be improved:
https://rise4fun.com/Alive/gBf
^ that pattern will be produced by Implicit Integer Truncation sanitizer,
https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530
in signed case, therefore it is probably a good idea to improve it.

Proofs for this transform: https://rise4fun.com/Alive/mgu
This transform is surprisingly frustrating.
This does not deal with non-splat shift amounts, or with undef shift amounts.
I've outlined what i think the solution should be:
```
  // Potential handling of non-splats: for each element:
  //  * if both are undef, replace with constant 0.
  //    Because (1<<0) is OK and is 1, and ((1<<0)>>1) is also OK and is 0.
  //  * if both are not undef, and are different, bailout.
  //  * else, only one is undef, then pick the non-undef one.
```

The DAGCombine will reverse this transform, see
https://reviews.llvm.org/D49266

Reviewers: spatel, craig.topper

Reviewed By: spatel

Subscribers: JDevlieghere, rkruppe, llvm-commits

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

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

[RegAlloc] Skip global splitting if the live range is huge and its spill is
trivially rematerializable.

We run into a case where machineLICM hoists a large number of live ranges
outside of a big loop because it thinks those live ranges are trivially
rematerializable. In regalloc, global splitting is tried out first for those
live ranges before they are spilled and rematerialized. Because the global
splitting algorithm is quadratic, increasing a lot of global splitting
candidates causes huge compile time increase (50s to 1400s on my local
machine when compiling a module).

However, we think for live ranges which are very large and are trivially
rematerialiable, it is better to just skip global splitting so as to save
compile time with little chance of sacrificing performance.  We uses the
segment size of live range to indirectly evaluate whether the global
splitting of the live range can introduce high cost, and use an option
as a knob to adjust the size limit threshold.

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

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

Restore "[ThinLTO] Ensure we always select the same function copy to import"

This reverts commit r337081, therefore restoring r337050 (and fix in
r337059), with test fix for bot failure described after the original
description below.

In order to always import the same copy of a linkonce function,
even when encountering it with different thresholds (a higher one then a
lower one), keep track of the summary we decided to import.
This ensures that the backend only gets a single definition to import
for each GUID, so that it doesn't need to choose one.

Move the largest threshold the GUID was considered for import into the
current module out of the ImportMap (which is part of a larger map
maintained across the whole index), and into a new map just maintained
for the current module we are computing imports for. This saves some
memory since we no longer have the thresholds maintained across the
whole index (and throughout the in-process backends when doing a normal
non-distributed ThinLTO build), at the cost of some additional
information being maintained for each invocation of ComputeImportForModule
(the selected summary pointer for each import).

There is an additional map lookup for each callee being considered for
importing, however, this was able to subsume a map lookup in the
Worklist iteration that invokes computeImportForFunction. We also are
able to avoid calling selectCallee if we already failed to import at the
same or higher threshold.

I compared the run time and peak memory for the SPEC2006 471.omnetpp
benchmark (running in-process ThinLTO backends), as well as for a large
internal benchmark with a distributed ThinLTO build (so just looking at
the thin link time/memory). Across a number of runs with and without
this change there was no significant change in the time and memory.

(I tried a few other variations of the change but they also didn't
improve time or peak memory).

The new commit removes a test that no longer makes sense
(Transforms/FunctionImport/hotness_based_import2.ll), as exposed by the
reverse-iteration bot. The test depends on the order of processing the
summary call edges, and actually depended on the old problematic
behavior of selecting more than one summary for a given GUID when
encountered with different thresholds. There was no guarantee even
before that we would eventually pick the linkonce copy with the hottest
call edges, it just happened to work with the test and the old code, and
there was no guarantee that we would end up importing the selected
version of the copy that had the hottest call edges (since the backend
would effectively import only one of the selected copies).

Reviewers: davidxl

Subscribers: mehdi_amini, inglorion, llvm-commits

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

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

[cfi-verify] Abort on unsupported targets

As suggested in the review for r337007, this makes cfi-verify abort on unsupported targets instead of producing incorrect results.  It also updates the design document to reflect this.

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

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

[InstrSimplify] add testcases for fold sdiv if two operands are negatived and non-overflow

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

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

[x86/SLH] Completely rework how we sink post-load hardening past data
invariant instructions to be both more correct and much more powerful.

While testing, I continued to find issues with sinking post-load
hardening. Unfortunately, it was amazingly hard to create any useful
tests of this because we were mostly sinking across copies and other
loading instructions. The fact that we couldn't sink past normal
arithmetic was really a big oversight.

So first, I've ported roughly the same set of instructions from the data
invariant loads to also have their non-loading varieties understood to
be data invariant. I've also added a few instructions that came up so
often it again made testing complicated: inc, dec, and lea.

With this, I was able to shake out a few nasty bugs in the validity
checking. We need to restrict to hardening single-def instructions with
defined registers that match a particular form: GPRs that don't have
a NOREX constraint directly attached to their register class.

The (tiny!) test case included catches all of the issues I was seeing
(once we can sink the hardening at all) except for the NOREX issue. The
only test I have there is horrible. It is large, inexplicable, and
doesn't even produce an error unless you try to emit encodings. I can
keep looking for a way to test it, but I'm out of ideas really.

Thanks to Ben for giving me at least a sanity-check review. I'll follow
up with Craig to go over this more thoroughly post-commit, but without
it SLH crashes everywhere so landing it for now.

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

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

[mips] Eliminate the usage of hasStdEnc in MipsPat.

Instead, the pattern is tagged with the correct predicate when
it is declared. Some patterns have been duplicated as necessary.

Patch by Simon Dardis.

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

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

[MIPS GlobalISel] Select instructions to load and store i32 on stack

Add code for selection of G_LOAD, G_STORE, G_GEP, G_FRAMEINDEX and
G_CONSTANT. Support loads and stores of i32 values.

Patch by Petar Avramovic.

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

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

[X86][AArch64][DAGCombine] Unfold 'check for [no] signed truncation' pattern

Summary:

[[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]]

As discussed in https://reviews.llvm.org/D49179#1158957 and later,
the IR for 'check for [no] signed truncation' pattern can be improved:
https://rise4fun.com/Alive/gBf
^ that pattern will be produced by Implicit Integer Truncation sanitizer,
https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530
in signed case, therefore it is probably a good idea to improve it.

But the IR-optimal patter does not lower efficiently, so we want to undo it..

This handles the simple pattern.
There is a second pattern with predicate and constants inverted.

NOTE: we do not check uses here. we always do the transform.

Reviewers: spatel, craig.topper, RKSimon, javed.absar

Reviewed By: spatel

Subscribers: kristof.beyls, llvm-commits

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

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

[Sparc] Use the correct encoding for ta 3

Summary: The old encoding generated a "tn %g1 + 3" instruction instead
of the expected "ta 3".

Reviewers: venkatra, jyknight

Reviewed By: jyknight

Subscribers: fedor.sergeev, jrtc27, llvm-commits

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

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

[Sparc] Use the names .rem and .urem instead of __modsi3 and __umodsi3

Summary: These are the names used in libgcc.

Reviewers: venkatra, jyknight, ekedaigle

Reviewed By: jyknight

Subscribers: joerg, fedor.sergeev, jrtc27, llvm-commits

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

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

[Sparc] Generate ta 1 for the @llvm.debugtrap intrinsic

Summary: Software trap number one is the trap used for breakpoints
in the Sparc ABI.

Reviewers: jyknight, venkatra

Reviewed By: jyknight

Subscribers: fedor.sergeev, jrtc27, llvm-commits

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

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

Avoid losing Hi part when expanding VAARG nodes on big endian machines

Summary:
If the high part of the load is not used the offset to the next element
will not be set correctly.

For example, on Sparc V8, the following code will read val2 from offset 4
instead of 8.

```
int val = __builtin_va_arg(va, long long);
int val2 = __builtin_va_arg(va, int);
```

Reviewers: jyknight

Reviewed By: jyknight

Subscribers: fedor.sergeev, jrtc27, llvm-commits

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

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

[x86/SLH] Fix a bug where we would try to post-load harden non-GPRs.

Found cases that hit the assert I added. This patch factors the validity
checking into a nice helper routine and calls it when deciding to harden
post-load, and asserts it when doing so later.

I've added tests for the various ways of loading a floating point type,
as well as loading all vector permutations. Even though many of these go
to identical instructions, it seems good to somewhat comprehensively
test them.

I'm confident there will be more fixes needed here, I'll try to add
tests each time as I get this predicate adjusted.

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

MSan: minor fixes, NFC

 - remove an extra space after |ID| declaration
 - drop the unused |FirstInsn| parameter in getShadowOriginPtrUserspace()

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

[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil.

For dsymutil we want to store offsets in the accelerator table entries
rather than DIE pointers. In addition, we need a way to communicate
which CU a DIE belongs to. This patch provides support for both of these
issues.

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

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

[x86/SLH] Extract another small helper function, add better comments and
use better terminology. NFC.

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

[AMDGPU][Waitcnt] Re-apply fix "comparison of integers of different signs" build error"

Re-apply "[AMDGPU][Waitcnt] fix "comparison of integers of different signs" build error""
( fe0a456510131f268e388c4a18a92f575c0db183 ), which was inadvertantly reverted via
2b2ee080f0164485562593b1b87291a48cea4a9a .

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

[MSan] factor userspace-specific declarations into createUserspaceApi(). NFC

This patch introduces createUserspaceApi() that creates function/global
declarations for symbols used by MSan in the userspace.
This is a step towards the upcoming KMSAN implementation patch.

Reviewed at https://reviews.llvm.org/D49292

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

run post-RA hazard recognizer pass late

Memory legalizer, waitcnt, and shrink  passes can perturb the instructions,
which means that the post-RA hazard recognizer pass should run after them.
Otherwise, one of those passes may invalidate the work done by the hazard
recognizer. Note that this has adverse side-effect that any consecutive
S_NOP 0's, emitted by the hazard recognizer, will not be shrunk into a
single S_NOP <N>. This should be addressed in a follow-on patch.

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

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

Revert "[AMDGPU][Waitcnt] fix "comparison of integers of different signs" build error"

This reverts commit fe0a456510131f268e388c4a18a92f575c0db183.

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

[MemorySSAUpdater] Remove deleted trivial Phis from active workset

Bug fix for PR37808. The regression test is a reduced version of the
original reproducer attached to the bug report. As stated in the report,
the problem was that InsertedPHIs was keeping dangling pointers to
deleted Memory-Phis. MemoryPhis are created eagerly and sometimes get
zapped shortly afterwards. I've used WeakVH instead of an expensive
removal operation from the active workset.

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

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

[X86] Merge the FR128 and VR128 regclass since they have identical spill and alignment characteristics.

This unfortunately requires a bunch of bitcasts to be added added to SUBREG_TO_REG, COPY_TO_REGCLASS, and instructions in output patterns. Otherwise tablegen seems to default to picking f128 and then we fail when something tries to get the register class for f128 which isn't always valid.

The test changes are because we were previously mixing fr128 and vr128 due to contrainRegClass finding FR128 first and passes like live range shrinking weren't handling that well.

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

[x86/SLH] Fix an unused variable warning in release builds after
r337144.

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

[x86/SLH] Teach speculative load hardening to correctly harden the
indices used by AVX2 and AVX-512 gather instructions.

The index vector is hardened by broadcasting the predicate state
into a vector register and then or-ing. We don't even have to worry
about EFLAGS here.

I've added a test for all of the gather intrinsics to make sure that we
don't miss one. A particularly interesting creation is the gather
prefetch, which needs to be marked as potentially "loading" to get the
correct behavior. It's a memory access in many ways, and is actually
relevant for SLH. Based on discussion with Craig in review, I've moved
it to be `mayLoad` and `mayStore` rather than generic side effects. This
matches how we model other prefetch instructions.

Many thanks to Craig for the review here.

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

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

[InstCombine] add more SPFofSPF folding

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

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

[InstCombine] fold icmp pred (sub 0, X) C for vector type

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

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

Recommit r335794 "Add support for generating a call graph profile from Branch Frequency Info." with fix for removed functions.

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

Prune empty directory.

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

[x86/SLH] Extract one of the bits of logic to its own function. NFC.

This is just a refactoring to start cleaning up the code here and make
it more readable and approachable.

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

[X86] Add custom execution domain fixing for 128/256-bit integer logic operations with AVX512F, but not AVX512DQ.

AVX512F only has integer domain logic instructions. AVX512DQ added FP domain logic instructions.

Execution domain fixing runs before EVEX->VEX. So if we have AVX512F and not AVX512DQ we fail to do execution domain switching of the logic operations. This leads to mismatches in execution domain and more test differences.

This patch adds custom domain fixing that switches EVEX integer logic operations to VEX fp logic operations if XMM16-31 are not used.

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

[X86] Add load patterns for cases where we select X86Movss/X86Movsd to blend instructions.

This allows us to fold the load during isel without waiting for the peephole pass to do it.

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

[X86] Use 128-bit blends instead vmovss/vmovsd for 512-bit vzmovl patterns to match AVX.

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

[X86] Use 128-bit ops for 256-bit vzmovl patterns.

128-bit ops implicitly zero the upper bits. This should address the comment about domain crossing for the integer version without AVX2 since we can use a 128-bit VBLENDW without AVX2.

The only bad thing I see here is that we failed to reuse an vxorps in some of the tests, but I think that's already known issue.

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

[DAGCombiner] fix typo in comment; NFC

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

[InstCombine] Corrections in comments for division transformation (NFC)

The actual code seems to be correct, but the comments were misleading.

Patch by Aaron Puchert!

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

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

[DAGCombiner] extend(ifpositive(X)) -> shift-right (not X)

This is almost the same as an existing IR canonicalization in instcombine,
so I'm assuming this is a good early generic DAG combine too.

The motivation comes from reduced bit-hacking for select-of-constants in IR
after rL331486. We want to restore that functionality in the DAG as noted in
the commit comments for that change and the llvm-dev discussion here:
http://lists.llvm.org/pipermail/llvm-dev/2018-July/124433.html

The PPC and AArch tests show that those targets are already doing something
similar. x86 will be neutral in the minimal case and generally better when
this pattern is extended with other ops as shown in the signbit-shift.ll tests.

Note the asymmetry: we don't include the (extend (ifneg X)) transform because
it already exists in SimplifySelectCC(), and that is verified in the later
unchanged tests in the signbit-shift.ll files. Without the 'not' op, the
general transform to use a shift is always a win because that's a single
instruction.

Alive proofs:
https://rise4fun.com/Alive/ysli

Name: if pos, get -1
  %c = icmp sgt i16 %x, -1
  %r = sext i1 %c to i16
  =>
  %n = xor i16 %x, -1
  %r = ashr i16 %n, 15

Name: if pos, get 1
  %c = icmp sgt i16 %x, -1
  %r = zext i1 %c to i16
  =>
  %n = xor i16 %x, -1
  %r = lshr i16 %n, 15

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

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

[InstSimplify] add fixme comment for PR37776; NFC

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

[AMDGPU] adjusted test checks because minnum with NaN gets simplified

This was improved with rL337127, but I missed the failure in this test.
I'm not sure what the expected result will be, so I've generalized it
and added a FIXME comment.

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

[InstSimplify] fold minnum/maxnum with NaN arg

This fold is repeated/misplaced in instcombine, but I'm
not sure if it's safe to remove that yet because some
other folds appear to be asserting that the transform
has occurred within instcombine itself.

This isn't the best fix for PR37776, but it probably
hides the bug with the given code example:
https://bugs.llvm.org/show_bug.cgi?id=37776

We have another test to demonstrate the more general bug.

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

[InstSimplify] add tests for minnum/maxnum; NFC

This isn't the best fix for PR37776, but it probably
hides the bug with the given code example:
https://bugs.llvm.org/show_bug.cgi?id=37776

We have another test to demonstrate the more general
bug.

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

[llvm-mca] Regenerate X86 specific tests. NFC

Not all tests were correctly updated by the update script after r336797.

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

[llvm-mca][BtVer2] teach how to identify false dependencies on partially written
registers.

The goal of this patch is to improve the throughput analysis in llvm-mca for the
case where instructions perform partial register writes.

On x86, partial register writes are quite difficult to model, mainly because
different processors tend to implement different register merging schemes in
hardware.

When the code contains partial register writes, the IPC (instructions per
cycles) estimated by llvm-mca tends to diverge quite significantly from the
observed IPC (using perf).

Modern AMD processors (at least, from Bulldozer onwards) don't rename partial
registers. Quoting Agner Fog's microarchitecture.pdf:
" The processor always keeps the different parts of an integer register together.
For example, AL and AH are not treated as independent by the out-of-order
execution mechanism. An instruction that writes to part of a register will
therefore have a false dependence on any previous write to the same register or
any part of it."

This patch is a first important step towards improving the analysis of partial
register updates. It changes the semantic of RegisterFile descriptors in
tablegen, and teaches llvm-mca how to identify false dependences in the presence
of partial register writes (for more details: see the new code comments in
include/Target/TargetSchedule.h - class RegisterFile).

This patch doesn't address the case where a write to a part of a register is
followed by a read from the whole register.  On Intel chips, high8 registers
(AH/BH/CH/DH)) can be stored in separate physical registers. However, a later
(dirty) read of the full register (example: AX/EAX) triggers a merge uOp, which
adds extra latency (and potentially affects the pipe usage).
This is a very interesting article on the subject with a very informative answer
from Peter Cordes:
https://stackoverflow.com/questions/45660139/how-exactly-do-partial-registers-on-haswell-skylake-perform-writing-al-seems-to

In future, the definition of RegisterFile can be extended with extra information
that may be used to identify delays caused by merge opcodes triggered by a dirty
read of a partial write.

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

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

[AVR] Document some public functions

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

[TableGen] std::move vectors into TreePatternNode.

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

[TableGen] Remove what seems to be an unnecessary std::map copy.

The comment says the copy was made so it could be destroyed in the following loop, but the original map wasn't used after the loop.

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

[X86] Add some optsize patterns for 256-bit X86vzmovl.

These patterns use VMOVSS/SD. Without optsize we use BLENDI instead.

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

[CMake] Pass CMAKE_INSTALL_DO_STRIP to external projects

This is necessary to make install-<target>-stripped work for
external projects such as runtimes.

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

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

[TableGen] Add some std::move to the PatternToMatch constructor.

The are two vectors passed by value to the constructor. We should be able to move them into the object.

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

[llvm-mca] Turn InstructionTables into a Stage.

Summary:
This patch converts the InstructionTables class into a subclass of mca::Stage.  This change allows us to use the Stage's inherited Listeners for event notifications.  This also allows us to create a simple pipeline for viewing the InstructionTables report.

I have been working on a follow on patch that should cleanup addView in InstructionTables.  Right now, addView adds the view to both the Listener list and Views list.  The follow-on patch addresses the fact that we don't really need two lists in this case.  That change is not specific to just InstructionTables, so it will be a separate patch.

Reviewers: andreadb, courbet, RKSimon

Reviewed By: andreadb

Subscribers: tschuett, gbedwell, llvm-commits

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

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

[NFC][InstCombine] foldICmpWithLowBitMaskedVal(): update comments.

All predicates are handled.
There does not seem to be any other possible folds here.
There are some more folds possible with inverted mask though.

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

[InstCombine] Fold  x & (-1 >> y) s< x  to  x s> (-1 >> y)

https://bugs.llvm.org/show_bug.cgi?id=38123
https://rise4fun.com/Alive/I3O

This pattern is not commutative!
We must make sure not to fold the commuted version!

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

[NFC][InstCombine] Tests for  x & (-1 >> y) s< x  to  x s> (-1 >> y)  fold.

https://bugs.llvm.org/show_bug.cgi?id=38123
https://rise4fun.com/Alive/I3O

This pattern is not commutative!
We must make sure not to fold the commuted version!

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

[InstCombine] Fold  x & (-1 >> y) s>= x  to  x s<= (-1 >> y)

https://bugs.llvm.org/show_bug.cgi?id=38123
https://rise4fun.com/Alive/I3O

This pattern is not commutative!
We must make sure not to fold the commuted version!

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

[NFC][InstCombine] Tests for  x & (-1 >> y) s>= x  to  x s<= (-1 >> y)  fold.

https://bugs.llvm.org/show_bug.cgi?id=38123
https://rise4fun.com/Alive/I3O

This pattern is not commutative!
We must make sure not to fold the commuted version!

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

[InstCombine] Fold  x s<= x & (-1 >> y)  to  x s<= (-1 >> y)

https://bugs.llvm.org/show_bug.cgi?id=38123
https://rise4fun.com/Alive/I3O

This pattern is not commutative!
We must make sure not to fold the commuted version!

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

[NFC][InstCombine] Tests for  x s<= x & (-1 >> y)  to  x s<= (-1 >> y)  fold.

https://bugs.llvm.org/show_bug.cgi?id=38123
https://rise4fun.com/Alive/I3O

This pattern is not commutative!
We must make sure not to fold the commuted version!

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

[InstCombine] Fold  x s> x & (-1 >> y)  to  x s> (-1 >> y)

https://bugs.llvm.org/show_bug.cgi?id=38123
https://rise4fun.com/Alive/I3O

This pattern is not commutative!
We must make sure not to fold the commuted version!

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

[NFC][InstCombine] Tests for  x s> x & (-1 >> y)  to  x s> (-1 >> y)  fold.

https://bugs.llvm.org/show_bug.cgi?id=38123
https://rise4fun.com/Alive/I3O

This pattern is not commutative!
We must make sure not to fold the commuted version!

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

[InstCombine] Fold  x u<= x & C  to  x u<= C

https://bugs.llvm.org/show_bug.cgi?id=38123
https://rise4fun.com/Alive/Fqp

This pattern is not commutative. But InstSimplify will
already have taken care of the 'commutative' variant.

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

[NFC][InstCombine] Tests for  x u<= x & C  to  x u<= C  fold.

https://bugs.llvm.org/show_bug.cgi?id=38123
https://rise4fun.com/Alive/Fqp

This pattern is not commutative. But InstSimplify will
already have taken care of the 'commutative' variant.

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

[InstCombine] Fold  x u> x & C  to  x u> C

https://bugs.llvm.org/show_bug.cgi?id=38123
https://rise4fun.com/Alive/JvS

This pattern is not commutative. But InstSimplify will
already have taken care of the 'commutative' variant.

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

[NFC][InstCombine] Tests for  x u> x & C  to  x u> C  fold.

https://bugs.llvm.org/show_bug.cgi?id=38123
https://rise4fun.com/Alive/JvS

This pattern is not commutative. But InstSimplify will
already have taken care of the 'commutative' variant.

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

[InstCombine] Fold  x & (-1 >> y) u< x  to  x u> (-1 >> y)

https://bugs.llvm.org/show_bug.cgi?id=38123
https://rise4fun.com/Alive/ocb

This pattern is not commutative. But InstSimplify will
already have taken care of the 'commutative' variant.

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

[NFC][InstCombine] Tests for  x & (-1 >> y) u< x  to  x u> (-1 >> y)

https://bugs.llvm.org/show_bug.cgi?id=38123
https://rise4fun.com/Alive/ocb

This pattern is not commutative. But InstSimplify will
already have taken care of the 'commutative' variant.

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

[InstCombine] Fold  x & (-1 >> y) u>= x  to  x u<= (-1 >> y)

https://bugs.llvm.org/show_bug.cgi?id=38123
https://rise4fun.com/Alive/azI

This pattern is not commutative. But InstSimplify will
already have taken care of the 'commutative' variant.

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

[NFC][InstCombine] Tests for  x & (-1 >> y) u>= x  to  x u<= (-1 >> y)

https://bugs.llvm.org/show_bug.cgi?id=38123
https://rise4fun.com/Alive/azI

This pattern is not commutative. But InstSimplify will
already have taken care of the 'commutative' variant.

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

[NFC][InstCombine] Add forgotten variable tests for foldICmpWithLowBitMaskedVal()

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

Attempt to get test/tools/llvm-lib/help.test passing on sanitizer-x86_64-linux-fast

The bot has a /b directory, so /? matches against that and gets expanded to it.

(Thanks to Hans's r187366, which solved the same problem for clang-cl a while
ago and which saved me much head scratching.)

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

[MachineOutliner] Check the last instruction from the sequence when updating liveness

The MachineOutliner was doing an std::for_each from the call (inserted
before the outlined sequence) to the iterator at the end of the
sequence.

std::for_each needs the iterator past the end, so the last instruction
was not taken into account when propagating the liveness information.

This fixes the machine verifier issue in machine-outliner-disubprogram.ll.

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

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

[x86/SLH] Fix an issue where we wouldn't harden any loads if we found
no conditions.

This is only valid to do if we're hardening calls and rets with LFENCE
which results in an LFENCE guarding the entire entry block for us.

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

[X86] Fix a subtle bug in the custom execution domain fixing for blends.

The code tried to find the immediate by using getNumOperands() on the MachineInstr, but there might be implicit-defs after the immediate that get counted.

Instead use getNumOperands() from the instruction description which will only count the operands that are defined in the td file.

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

Give llvm-lib rudimentary help output.

https://reviews.llvm.org/D49318

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

[X86] Prefer blendi over movss/sd when avx512 is enabled unless optimizing for size.

AVX512 doesn't have an immediate controlled blend instruction. But blend throughput is still better than movss/sd on SKX.

This commit changes AVX512 to use the AVX blend instructions instead of MOVSS/MOVSD. This constrains the register allocation since it won't be able to use XMM16-31, but hopefully the increased throughput and reduced port 5 pressure makes up for that.

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

Revert "[ThinLTO] Ensure we always select the same function copy to import"

This reverts commits r337050 and r337059. Caused failure in
reverse-iteration bot that needs more investigation.

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

Revert "[ThinLTO] Add debug output to test"

This reverts commit r337076. Not needed any more.

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

Revert "AMDGPU: Fix handling of alignment padding in DAG argument lowering"

This reverts commit r337021.

WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x1415cd65 in void write_signed<long>(llvm::raw_ostream&, long, unsigned long, llvm::IntegerStyle) /code/llvm-project/llvm/lib/Support/NativeFormatting.cpp:95:7
    #1 0x1415c900 in llvm::write_integer(llvm::raw_ostream&, long, unsigned long, llvm::IntegerStyle) /code/llvm-project/llvm/lib/Support/NativeFormatting.cpp:121:3
    #2 0x1472357f in llvm::raw_ostream::operator<<(long) /code/llvm-project/llvm/lib/Support/raw_ostream.cpp:117:3
    #3 0x13bb9d4 in llvm::raw_ostream::operator<<(int) /code/llvm-project/llvm/include/llvm/Support/raw_ostream.h:210:18
    #4 0x3c2bc18 in void printField<unsigned int, &(amd_kernel_code_s::amd_kernel_code_version_major)>(llvm::StringRef, amd_kernel_code_s const&, llvm::raw_ostream&) /code/llvm-project/llvm/lib/Target/AMDGPU/Utils/AMDKernelCodeTUtils.cpp:78:23
    #5 0x3c250ba in llvm::printAmdKernelCodeField(amd_kernel_code_s const&, int, llvm::raw_ostream&) /code/llvm-project/llvm/lib/Target/AMDGPU/Utils/AMDKernelCodeTUtils.cpp:104:5
    #6 0x3c27ca3 in llvm::dumpAmdKernelCode(amd_kernel_code_s const*, llvm::raw_ostream&, char const*) /code/llvm-project/llvm/lib/Target/AMDGPU/Utils/AMDKernelCodeTUtils.cpp:113:5
    #7 0x3a46e6c in llvm::AMDGPUTargetAsmStreamer::EmitAMDKernelCodeT(amd_kernel_code_s const&) /code/llvm-project/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp:161:3
    #8 0xd371e4 in llvm::AMDGPUAsmPrinter::EmitFunctionBodyStart() /code/llvm-project/llvm/lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp:204:26

[...]

Uninitialized value was created by an allocation of 'KernelCode' in the stack frame of function '_ZN4llvm16AMDGPUAsmPrinter21EmitFunctionBodyStartEv'
    #0 0xd36650 in llvm::AMDGPUAsmPrinter::EmitFunctionBodyStart() /code/llvm-project/llvm/lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp:192

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

[x86/SLH] Add an assert to catch if we ever end up trying to harden
post-load a register that isn't valid for use with OR or SHRX.

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

[llvm-mca] Remove unused InstRef formal from pre and post execute callbacks. NFC.

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

[ThinLTO] Add debug output to test

Add -debug-only=function-import to get more information for debugging
reverse-iteration bot failure from r337050.

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

Re-apply "[SCEV] Strengthen StrengthenNoWrapFlags (reapply r334428)."

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

Add a CHECK line for r337072.

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

[Hexagon] Avoid introducing calls into coalesced range of HVX vector pairs

If an HVX vector register is to be coalesced into a vector pair, make
sure that the vector pair will not have a function call in its live range,
unless it already had one. All HVX vector registers are volatile, so
any vector register live across a function call will have to be spilled.

If a vector needs to be spilled, and it's coalesced into a vector pair
then the whole pair will need to be spilled (even if only a part of it is
live), taking extra stack space.

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

[LSR] If no Use is interesting, early return.

Summary:
By looking at the callers of getUse(), we can see that even though
IVUsers may offer uses, but they may not be interesting to
LSR. It's possible that none of them is interesting.

Reviewers: sanjoy

Subscribers: jlebar, hiraditya, bixia, llvm-commits

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

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

[X86][SLH] Remove PDEP and PEXT from isDataInvariantLoad

Ryzen has something like an 18 cycle latency on these based on Agner's data. AMD's own xls is blank. So it seems like there might be something tricky here.

Agner's data for Intel CPUs indicates these are a single uop there.

Probably safest to remove them. We never generate them without an intrinsic so this should be ok.

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

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

[X86][SLH] Add VEX and EVEX conversion instructions to isDataInvariantLoad

-Drop the intrinsic versions of conversion instructions. These should be handled when we do vectors. They shouldn't show up in scalar code.
-Add the float<->double conversions which were missing.
-Add the AVX512 and AVX version of the conversion instructions including the unsigned integer conversions unique to AVX512

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

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

[X86][SLH] Regroup the instructions in isDataInvariantLoad a little. NFC

-Move BSF/BSR to the same group as TZCNT/LZCNT/POPCNT.
-Split some of the bit manipulation instructions away from TZCNT/LZCNT/POPCNT. These are things like 'x & (x - 1)' which are composed of a few simple arithmetic operations. These aren't nearly as complicated/surprising as counting bits.
-Move BEXTR/BZHI into their own group. They aren't like a simple arithmethic op or the bit manipulation instructions. They're more like a shift+and.

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

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

[docs] Update usage directive for llvm-cov report -show-functions

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

Fix comments which mixed up 'before' and 'after', NFC

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

Clarify wording of a doxygen comment, NFC

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

[ThinLTO] Require x86 target for new test

Should fix non-x86 bot failures for new test from r337050.

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

[X86] Use the correct types in some recently added isel patterns.

These were supposed to be integer types since we are selecting integer instructions.

Found while preparing to remove these patterns for another patch.

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

AMDGPU/GlobalISel: Implement select() for 32-bit @llvm.minnun and @llvm.maxnum

Reviewers: arsenm, nhaehnle

Subscribers: kzhuravl, wdng, yaxunl, rovka, kristof.beyls, dstuttard, tpr, llvm-commits, t-tye

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

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

[X86][FastISel] Support uitofp with avx512.

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

[LTO] Fix linking with an alias defined using another alias.

When we're linking an alias which will be defined later, we neeed to
build a GlobalAlias, or else we'll crash later in
IRLinker::linkGlobalValueBody.

clang sometimes constructs aliases like this for C++ destructors.

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

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

[X86] Correct comment of TEST elimination in BSF/TZCNT

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

[ThinLTO] Ensure we always select the same function copy to import

In order to always import the same copy of a linkonce function,
even when encountering it with different thresholds (a higher one then a
lower one), keep track of the summary we decided to import.
This ensures that the backend only gets a single definition to import
for each GUID, so that it doesn't need to choose one.

Move the largest threshold the GUID was considered for import into the
current module out of the ImportMap (which is part of a larger map
maintained across the whole index), and into a new map just maintained
for the current module we are computing imports for. This saves some
memory since we no longer have the thresholds maintained across the
whole index (and throughout the in-process backends when doing a normal
non-distributed ThinLTO build), at the cost of some additional
information being maintained for each invocation of ComputeImportForModule
(the selected summary pointer for each import).

There is an additional map lookup for each callee being considered for
importing, however, this was able to subsume a map lookup in the
Worklist iteration that invokes computeImportForFunction. We also are
able to avoid calling selectCallee if we already failed to import at the
same or higher threshold.

I compared the run time and peak memory for the SPEC2006 471.omnetpp
benchmark (running in-process ThinLTO backends), as well as for a large
internal benchmark with a distributed ThinLTO build (so just looking at
the thin link time/memory). Across a number of runs with and without
this change there was no significant change in the time and memory.

(I tried a few other variations of the change but they also didn't
improve time or peak memory).

Reviewers: davidxl

Subscribers: mehdi_amini, inglorion, llvm-commits

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

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