[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

AMDGPU/GlobalISel: Implement select() for @llvm.amdgcn.exp

Reviewers: arsenm, nhaehnle

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

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

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

[X86][FastISel] Add EVEX support to sitofp handling.

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

[X86] Try fixing r336768

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

[NFC][InstCombine] Tests for 'check for [no] signed truncation' pattern

[[ 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.

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

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

Revert "[CMake] Pass Clang defaults to runtimes builds"

This reverts commit r332923 which is no longer needed since its
use has been reverted in r337033.

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

[LowerTypeTests] Limit when icall jumptable entries are emitted

Summary:
Currently LowerTypeTests emits jumptable entries for all live external
and address-taken functions; however, we could limit the number of
functions that we emit entries for significantly.

For Cross-DSO CFI, we continue to emit jumptable entries for all
exported definitions.  In the non-Cross-DSO CFI case, we only need to
emit jumptable entries for live functions that are address-taken in live
functions. This ignores exported functions and functions that are only
address taken in dead functions. This change uses ThinLTO summary data
(now emitted for all modules during ThinLTO builds) to determine
address-taken and liveness info.

The logic for emitting jumptable entries is more conservative in the
regular LTO case because we don't have summary data in the case of
monolithic LTO builds; however, once summaries are emitted for all LTO
builds we can unify the Thin/monolithic LTO logic to only use summaries
to determine the liveness of address taking functions.

This change is a partial fix for PR37474. It reduces the build size for
nacl_helper by ~2-3%, the reduction is due to nacl_helper compiling in
lots of unused code and unused functions that are address taken in dead
functions no longer being being considered live due to emitted jumptable
references. The reduction for chromium is ~0.1-0.2%.

Reviewers: pcc, eugenis, javed.absar

Reviewed By: pcc

Subscribers: aheejin, dexonsmith, dschuff, mehdi_amini, eraman, steven_wu, llvm-commits, kcc

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

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

[dwarfdump] Add pretty printer for accelerator table based on Atom.

For instance, When dumping .apple_types, the second atom represents the
DW_TAG. In addition to printing the raw value, we now also pretty print
the value if the ATOM tells us how.

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

[llvm-mca][BtVer2] Add tests for dependency breaking instructions.

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

[TableGen] Suppress type validation when parsing pattern fragments

Currently, any attempt to define a PatFrag involving any floating-point
only (or vector only) node causes a hard assertion failure in TableGen
if the current target does not have any floating-point (or vector)
types.

This is annoying if you want to provide convenience fragments in common
code (e.g. include/llvm/Target/TargetSelectionDAG.td) that is parsed on
all platforms, including those that miss such types.

But really, there's no reason not accept this when parsing the fragment
-- of course it would be an error for such a target to actually *use*
such a fragment anywhere, but as long as it doesn't, I think TableGen
shouldn't error out.

The immediate cause of the assertion failure is the test inside the
ValidateOnExit destructor. This patch simply disables that check while
infering types during parsing of pattern fragments (only).

Reviewed By: hfinkel, kparzysz

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

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

AMDGPU: Properly handle shader inputs with split arguments

This needs to refer to arguments by their original argument
index, not the argument split index which depends on what
the type splitting decides to do.

Also avoid increment PSInputNum for each split piece.

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

AMDGPU: Fix handling of alignment padding in DAG argument lowering

This was completely broken if there was ever a struct argument, as
this information is thrown away during the argument analysis.

The offsets as passed in to LowerFormalArguments are not useful,
as they partially depend on the legalized result register type,
and they don't consider the alignment in the first place.

Ignore the Ins array, and instead figure out from the raw IR type
what we need to do. This seems to fix the padding computation
if the DAG lowering is forced (and stops breaking arguments
following padded arguments if the arguments were only partially
lowered in the IR)

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

[Tablegen] Optimize isSubsetOf() in AsmMatcherEmitter.cpp. NFC

isSubsetOf() could be very slow if the hierarchy of the RegisterClasses
of the target is very complicated.
This is mainly caused by the fact that isSubset() is called
multiple times over the same SuperClass of a register class
if this ends up being the super class of a register class
from multiple paths.

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

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

Revert "CallGraphSCCPass: iterate over all functions."

This reverts commit r336419: use-after-free on CallGraph::FunctionMap elements
due to the use of a stale iterator in CGPassManager::runOnModule.

The iterator may be invalidated if a pass removes a function, ex.:
  llvm::LegacyInlinerBase::inlineCalls
  inlineCallsImpl
  llvm::CallGraph::removeFunctionFromModule

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

[NFC][X86][AArch64] Negative tests for 'check for [no] signed truncation' pattern

See D49247, D49266

I'm only adding the sane negative tests, and not
adding the one-use tests yet. Also, not adding
negative tests for the second pattern with inverted operands yet,
since it's handling will be added in later differential.

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

[cfi-verify] Only run AArch64 tests when it is a supported target

This stops the tests I added in r337007 from running when AArch64 is not a supported target.

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

[dwarfdump] Pretty print DW_AT_APPLE_runtime_class

Instead of printing

  DW_AT_APPLE_runtime_class       (0x10)

we now print

  DW_AT_APPLE_runtime_class       (DW_LANG_ObjC)

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

[AArch64] Armv8.4-A: LDAPR & STLR with immediate offset instructions (cont'd)

Follow up of rL336913: fix base class description. Thanks to Ahmed Bougacha
for pointing this out.

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

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

[PowerPC] Materialize more constants with CR-field set in late peephole

Revision r322373 fixed a bug in how we materialize constants when the CR-field
needs to be set.

However the fix is overly conservative. It will only do the transform if
AND-ing the input with the new constant produces the same new constant.
This is of course correct, but not necessarily required.

If there are no futher uses of the constant, the constant can be changed.
If there are no uses of the GPR result, the final result of the materialization
isn't important other than it needs to compare to zero correctly (lt, gt, eq).

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

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

[cfi-verify] Support AArch64.

This patch adds support for AArch64 to cfi-verify.

This required three changes to cfi-verify.  First, it generalizes checking if an instruction is a trap by adding a new isTrap flag to TableGen (and defining it for x86 and AArch64).  Second, the code that ensures that the operand register is not clobbered between the CFI check and the indirect call needs to allow a single dereference (in x86 this happens as part of the jump instruction).  Third, we needed to ensure that return instructions are not counted as indirect branches.  Technically, returns are indirect branches and can be covered by CFI, but LLVM's forward-edge CFI does not protect them, and x86 does not consider them, so we keep that behavior.

In addition, we had to improve AArch64's code to evaluate the branch target of a MCInst to handle calls where the destination is not the first operand (which it often is not).

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

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

[json, test] Fix the json.td test - the path to python could contain spaces

Summary: The path to the python executable can contain spaces, so it should be specified with quotes.

Reviewers: asmith, simon_tatham

Reviewed By: simon_tatham

Subscribers: llvm-commits

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

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

[mips] Add microMIPS case to the tests and regenerate assertions using update_llc_test_checks.py. NFC

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

[llvm-mca] Improve a few debug prints. NFC

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

Add parens to silence Wparentheses warning, introduced by 336990

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

[NFC] Silence Wparentheses warning in DomTreeUpdater, introduced by 336968

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